Just wondering, are there any situations which occur when an IRQ mask can be set or unset by hardware and not by an explicit software instruction? Say for example, if IRQ 3 fires, can that firing cause IRQ 4 to mask itself? Or can a PCI device modify an IRQ mask itself?
Can I assume that the kernel is in complete control of the IRQ masking and unmasking?
IRQ masks.
Re:IRQ masks.
Yes and no. The IRQ firing will cause the cpu to start executing the IRQ handler and temporarily mask the lower priority irq's (4+) in the (A)PIC. However, as soon as your handler finishes and sends the EOI (automatically or manually) to the PIC, it'll fire the other interrupts after that.durand wrote: Just wondering, are there any situations which occur when an IRQ mask can be set or unset by hardware and not by an explicit software instruction? Say for example, if IRQ 3 fires, can that firing cause IRQ 4 to mask itself? Or can a PCI device modify an IRQ mask itself?
Nothing that can happen during your kernels running time can affect the permanent masking of interrupts. Note however that it can affect temporary masking or simply not fire interrupts anymore due to any sort of malfunction. Hardware cannot be guaranteed, so software must cope with that. You can try to ensure my data using all sorts of software techniques but if I take a mallet and pound the **** out of the disks on which it's stored, I'm very certain those techniques don't help. On a sidenote, the disk probably won't give any interrupts after that either.
So, that's a yes.Can I assume that the kernel is in complete control of the IRQ masking and unmasking?
Re:IRQ masks.
thanks. 
-
Kemp
Re:IRQ masks.
Interrupt 42 : Oh My Freakin' God, Call A Technician!
This interrupt may be raised by hardware experiencing difficulties involving mallets or other large beating implements.
This interrupt may be raised by hardware experiencing difficulties involving mallets or other large beating implements.
-
Crazed123
Re:IRQ masks.
I've seen it a fairly standard practice to do a cli as soon as we enter the ISR, so does that EOI signal reenable interrupts? The iret?Candy wrote: Yes and no. The IRQ firing will cause the cpu to start executing the IRQ handler and temporarily mask the lower priority irq's (4+) in the (A)PIC. However, as soon as your handler finishes and sends the EOI (automatically or manually) to the PIC, it'll fire the other interrupts after that.
-
AR
Re:IRQ masks.
Depending on the type if the interrupt handler it can disable interrupts automatically, the IRET restores EFLAGS (therefore interrupts). If CLI is used in the ASM wrapper then it's most likely the author didn't know what they were doing.
Re:IRQ masks.
The PIC sends interrupts to the CPU after the EOI. The CPU only processes them when the interruptflag is set.Crazed123 wrote:I've seen it a fairly standard practice to do a cli as soon as we enter the ISR, so does that EOI signal reenable interrupts? The iret?Candy wrote: Yes and no. The IRQ firing will cause the cpu to start executing the IRQ handler and temporarily mask the lower priority irq's (4+) in the (A)PIC. However, as soon as your handler finishes and sends the EOI (automatically or manually) to the PIC, it'll fire the other interrupts after that.
Doing a CLI in an interrupt gate is wrong however (this is from a theoretical standpoint, I think I do that myself too). The interrupt gate itself clears the interrupt bit and pushes the old flags, so you don't have to do that. The IRET pops the flags back off, so if they were enabled before the interrupt, they'll be reenabled. The STI function is defined such that if you do CLI ...... STI IRET it'll work properly, since STI allows the first instruction after it to finish before actually turning the interrupts back on.