IRQ 7 fires

[bluecode]

@Speek: no there are exceptions (cpu generated), hardware interrupts and software interrupts (int XX).

[DynatOS]

@Speek: no there are exceptions (cpu generated), hardware interrupts and software interrupts (int XX).

You challenged me, so I refreshed myself on the subject to make sure

Interrupts are triggered by hardware external to the CPU. Exceptions are triggered internally by the CPU.

Considering that the list of Interrupts covers IRQ/NMI (i.e. hardware) and the list of Exceptions covers fault/abort/trap/INT/INT3/INTO/BOUND (i.e. caused by/for software)... I am going to have to reinforce the advice I gave in my last post to this thread. Deny spurious Interrupts, and examine Exceptions to determine what to do with them.

PS: I tend to get my info from the horse's mouth (manufacturer's reference manuals in this case)... I rarely adhere to slang or "common" knowledge

[Candy]

Just keep it simple for yourself, don't overburden yourself with pointless logic.

Exceptions are between 0x0 and 0x1F. Do not map anything there except exception handlers, limit to CPL0 and pray no cpl0 code will call them explicitly.

Map your hardware interrupts to some other place, suggestion of 0x20 - 0x2F. Don't allow software interrupts there, pray cpl0 code will not call them.

Map any other interrupts >= 0x30.

No checks needed, just define everything as ok and it will be.

[Ryu]

The PIC chips aren't designed to handle multiple CPUs. To be honest, I'm not sure if an IRQ from the PIC would go to all CPUs at the same time (which would need to be prevented), or if it'd go to the BSP (boot CPU) only In any case, I'd completely disable the PIC chips and use the I/O APIC/s instead.

Anyone else has found something really strange with here? Brendan isn't sure!? ::is that even possible??::.

Its time I move onto I/O APICs.

[Candy]

Anyone else has found something really strange with here? Brendan isn't sure!? ::is that even possible??::.

You mean, he's human? Wow, did expect that.