Multitasking disables interrupts

[Creature]

I have another question and/or problem; is there any way multitasking (or context switching) would disable interrupts (of all kinds)? When I fork() in my OS and the function returns, my OS prints a certain string, after which the PIT switches contexts and the second 'process' prints the same string (as it should). But after both processes have had their timeslice (and the PIT switched once), interrupts just stop working. The PIT isn't called anymore, the keyboard gets disabled and I've made sure that every time I disable interrupts, they are enabled correctly again. I've even tried to let both processes re-enable interrupts, with no result however. I do not get a CPU fault or trap of any kind, execution just plainly continues as it should, but interrupts are disabled.

Any idea's why this would happen? Is it possible that the CPU does not allow interrupts in the newly process originated from the fork()? As this would be strange, as how else am I supposed to change contexts again?

Thanks,
Creature

[xenos]

Just a few suggestions:

• Are you sure that interrupts are disabled, i.e. have you checked the IF in the EFLAGS register? If just re-enabling interrupts does not change anything, the problem might be in some other place. (Or they are disabled again?)
• Do all of your interrupt handlers send an end-of-interrupt to the PIC before returning?
• Are you running on a real box or something like bochs? Using bochs you can create a log file with option debug=report. (Be careful, that can result in a really huge log file!) Then you can check when interrupts are disabled / enabled, the PIC is notified etc.

[Creature]

Are you sure that interrupts are disabled, i.e. have you checked the IF in the EFLAGS register? If just re-enabling interrupts does not change anything, the problem might be in some other place. (Or they are disabled again?)

I'll check a few times over again soon.

Do all of your interrupt handlers send an end-of-interrupt to the PIC before returning?

Yes, every interrupt goes through the same procedure. The interrupts work fine at first, but only work if I fork() a process or actually start using more than 1 process in any way.

Are you running on a real box or something like bochs? Using bochs you can create a log file with option debug=report. (Be careful, that can result in a really huge log file!) Then you can check when interrupts are disabled / enabled, the PIC is notified etc.

The Bochs log file is huge, indeed. According to the file, my timer is called perfectly like in the beginning, but for some reason I'm not getting any timer signal nor keyboard input events and such.

[hailstorm]

I once had the same problem, when I implemented multitasking in my OS. It worked out that, as soon as I switched to the second task, the interrupt handler didn't finish, because the second task wasn't aware of the ISR being executed (since the EIP of the interrupt handler resides on the other task's kernelstack). If this is the case with your kernel, you have to modify your ISR's, so that a end of interrupt is always sent to the PIC.

Hope this helps, good luck!

Greetz.

[Creature]

I once had the same problem, when I implemented multitasking in my OS. It worked out that, as soon as I switched to the second task, the interrupt handler didn't finish, because the second task wasn't aware of the ISR being executed (since the EIP of the interrupt handler resides on the other task's kernelstack). If this is the case with your kernel, you have to modify your ISR's, so that a end of interrupt is always sent to the PIC.

Hope this helps, good luck!

Greetz.

Thank you VERY much, I'm deeply disappointed in myself . You gave me some golden advice there, this was indeed what was happening. I let my IRQ handler acknowlede the IRQ AFTER the task switching occurred. This way the switching occurred but the IRQ handler never acknowledged anything. It's fixed now (FINALLY).

Thanks for your time and advice .

[hailstorm]

I'm just glad I could help. This problem also gave me a headache and a hard time to solve it.