OSDev.org

Should i always check in my irq handler if interrupt really came from the controller?
The problem is i do not know how to treat spurious interrupts wich as i understand it can be generated by hardware malfunction when cpus intr pin is jumped by charge from other line.
Are spurious interrupts part of x86 design, or its a malfunction and there is nothing i can nor should do about it?

Hi,

a5498828 wrote:Should i always check in my irq handler if interrupt really came from the controller?

Only for IRQ7 and IRQ15 when you're using the PIC/s. The local APIC has it's own separate spurious interrupt (which doesn't conflict with any actual IRQ).

For IRQ7, check the master PIC's ISR to see if it was a real IRQ7 or not. If it wasn't, don't send an EOI or anything.

For IRQ15, check the slave PIC's ISR to see if it was a real IRQ15 or not. If it wasn't, send an EOI to the master PIC but not to the slave PIC.

a5498828 wrote:Are spurious interrupts part of x86 design, or its a malfunction and there is nothing i can nor should do about it?

It's part of the design, mostly intended to get around race conditions.

Normally when an IRQ occurs, the PIC chip tells the CPU "I've got an interrupt for you", then CPU replies "What is it?" and the PIC tells the CPU which interrupt vector. The problem is that the interrupt can disappear (either because software sent EOI or did something else) after the PIC chip tells the CPU it has an interrupt but before the PIC chip tells the CPU which interrupt vector. In this case, the CPU is waiting for a reply from the PIC and the PIC chip has to tell the CPU an interrupt vector, so it tells the CPU "it's a spurious IRQ" because the original interrupt disappeared.


Cheers,

Brendan

//seems that post i replied to was deleted...


About osdev wiki: http://wiki.osdev.org/Non_Maskable_Interrupt
When enabling/disabling NMI shouldnt it be followed by read/write to port 0x71?
and isnt 0x70 write only? Return 0xFF on reads.


about this thread, wiki doesnt say more than i already know.
spurious interrupt is unwanted interrupt delivered as a result of interference.

pic wil rise irq7 is cpu send him inta on interrupt that hasnt been sent. Ok, but irq7 is a paralell port according to some documentations. Slave can also generate spurious irq15 is something not important to me now happens. So we have irq7 and irq15 potentially being empty. But what happens to cpu when intr is triggered by noise?

Wiki doesnt say that. In fact it doesnt say amything, the only thing i use it is lookup of gdt/idt bits, although i propably learned them by now.

Normally when an IRQ occurs, the PIC chip tells the CPU "I've got an interrupt for you", then CPU replies "What is it?" and the PIC tells the CPU which interrupt vector. The problem is that the interrupt can disappear (either because software sent EOI or did something else) after the PIC chip tells the CPU it has an interrupt but before the PIC chip tells the CPU which interrupt vector. In this case, the CPU is waiting for a reply from the PIC and the PIC chip has to tell the CPU an interrupt vector, so it tells the CPU "it's a spurious IRQ" because the original interrupt disappeared.

Ok i get it. If cpu sent eoi without getting vector its a programmer bug, why pic should correct it? It should do nothing.
I read its because of noise on intr pin. So whats right?

The FAQ has instructions on dealing with spurious interrupts from the PIC. If you have such noise on the CPU socket to get other causes of spurious interrupts, you need new hardware.

Hi,

a5498828 wrote:About osdev wiki: http://wiki.osdev.org/Non_Maskable_Interrupt
When enabling/disabling NMI shouldnt it be followed by read/write to port 0x71?
and isnt 0x70 write only? Return 0xFF on reads.

Sorry - I can't remember much about how NMI should be enabled/disabled. My opinion on this is that NMI should never be enabled/disabled (despite Intel and AMD's advice).

For things like watchdog timers disabling NMI doesn't make much sense; and ignoring hardware faults is just plain bad. Intel and AMD suggest disabling NMI during CPU mode switches (e.g. when you're switching from real mode to protected mode or something) where you can't have a valid NMI handler in place. In this case (in my opinion) it's far better to set the IDT limit to zero (so that an NMI will cause a triple fault), then do the CPU mode switch, then setup a valid IDT. That way you aren't ignoring hardware faults and you are automatically doing the only sane thing you possible can do in that situation (reset the computer).

a5498828 wrote:about this thread, wiki doesnt say more than i already know.

I was too slow (but I've added some information on spurious IRQs to the wiki's PIC page).

a5498828 wrote:

Normally when an IRQ occurs, the PIC chip tells the CPU "I've got an interrupt for you", then CPU replies "What is it?" and the PIC tells the CPU which interrupt vector. The problem is that the interrupt can disappear (either because software sent EOI or did something else) after the PIC chip tells the CPU it has an interrupt but before the PIC chip tells the CPU which interrupt vector. In this case, the CPU is waiting for a reply from the PIC and the PIC chip has to tell the CPU an interrupt vector, so it tells the CPU "it's a spurious IRQ" because the original interrupt disappeared.

Ok i get it. If cpu sent eoi without getting vector its a programmer bug, why pic should correct it? It should do nothing.
I read its because of noise on intr pin. So whats right?

If PIC does nothing, then the CPU sits there doing nothing waiting for an interrupt number that never arrives, and (as a worst case) maybe the entire computer locks up. That's a lot less graceful...

a5498828 wrote:I read its because of noise on intr pin. So whats right?

Both!


Cheers,

Brendan

nmi must be disabled when writing CMOS, otherwise you have a problem after reset as the data is inconsistent or no access followinf write to 0x71 was done.

So about spurious interrupt, the only action i should take when receiving it, is reset, right? It wont come up in normal operation?
So check irq7/15 for isr, if 0 - reset.


I also dont understand much about PIC. It has so many options... For example, eoi. There are many diffrent options for signaling eoi, bit 7-5 = 000 rotate in auto EOI mode (clear)
= 001 nonspecific EOI
= 010 no operation
= 011 specific EOI
= 100 rotate in auto EOI mode (set)
= 101 rotate on nonspecific EOI command
= 110 set priority command
= 111 rotate on specific EOI command


i dont understand them. Where should i seek help?


Or modes of operation:
bit 7-5 = 0 reserved
bit 4 = 0 no special fully-nested mode
= 1 special fully-nested mode
bit 3-2 = 0x nonbuffered mode
= 10 buffered mode/slave
= 11 buffered mode/master
bit 1 = 0 normal EOI
= 1 Auto EOI
bit 0 = 0 8085 mode
= 1 8086/8088 mode
i understand only eoi/aeoi (aeoi isnt reliable, is it?). rest is just random words for me wich make no sense.
How im supposed to learn it, if i search full day for basic explanations 'HOW DOES IT WORK', finding either contradictory information, or no at all. Its just a waste of time, you seem to know it all, where did you learned it? Good exampe is PIC. Where will i find full specs of it? Im interested in its programming interface, not hardware btw.

a5498828 wrote:Im interested in its programming interface, not hardware btw.

Then skip the first few chapters of the relevant manual. Note that information on the programming interface alone will not tell you how a device actually operates so if you keep skipping those parts you will keep your gaps in your understanding. For the documents that do not have information beyond the programming interface, you will have to go through each programmable option to see if its relevant for that particular step, a rather dreary and error-prone task.

Most of what I know about the PIC I learned from its datasheet. Is it really that hard to understand? Even the 8253 datasheet isn't that hard, and it's more complicated than the 8259. I find the software-oriented specifications, like ACPI, PnP BIOS, BIOS boot spec, and SMBIOS, to be vastly more difficult to understand. If you are having trouble understanding the data sheet, then search google. For example, looking up "8259 PIC" gets me not only the datasheet, but the wikipedia and OSDev wiki articles, as well as other websites describing it. One of them I found extremely useful, see if you can find it yourself.

its not im having trouble, but im finding garbage.

For example, yesterday ive found that port (byte) 0xA0 is an nmi port. If i write 80 its nmi disable, 00 its nmi enable, much like in port 0x70 but i dont have to read anything else, or list simply doesnt state that in case of 0xA0.

http://bochs.sourceforge.net/techspec/PORTS.LST

pic use to ports, 20 and 21.
read from 20 is ocw2 or 3, depending on prevoius write. write to 20 is either icw1 or ocw2/3 depending on bit 3 (or 4 with icw). Port 21 is icw2/3/4 and imr.


How does mni fit into it? write to 0x20 (A0, but 20 is exactly same) of 80 is 'rotate in eoi mode'. Howe does mni fit into it?!! Talking about garbage.


port 0462 is nmi trigger. Of course it doesnt work. Why? I have mni enabled via:
outb 0x70, 0x00
inb 0x71
And vector 2 in ivt set to jmp $. Why doesnt it work?

Why should the PIC datasheet tell you anything about the PC? It wasn't designed for the PC; it was designed for any device built upon an 8008, 8080 or 808[8/6] CPU...

What you need is one of the many 3rd party PC hardware reference manuals...

this isnt about PIC alone, its about searching information by myself.
So how about this nmi?

and about pic, what happens when i read port 0x20 without writing ocw3 first?
datasheet doesnt say. And its always like this. It doesnt say, i have to spam forums or test on my own wich isnt always reliable.

First off, NMIs are completely separate from the PIC. The reason they are called non-maskable is because they bypass any kind of PIC and go directly to an #NMI pin on the processor. You can disable them, but the method to do so is completely separate from the PIC, and depends on the computer.

Spurious interrupts are part of the PIC and they are always the lowest priority interrupt. Which means that they are indicated by the IR7 pin for both the master and slave PICs. Mapping that to IRQ numbers, it becomes 7 (master) and 15 (slave). The main difference from spurious interrupts and regular IRQs is that you don't send an EOI. This can be detected by checking the interrupt/IRQ number.

a5498828 wrote:and about pic, what happens when i read port 0x20 without writing ocw3 first? datasheet doesnt say.

The Official 8259A datasheet wrote:There is no need to write an OCW3 before every
status read operation as long as the status read
corresponds with the previous one i e the 8259A
‘‘remembers’’ whether the IRR or ISR has been pre-
viously selected by the OCW3 This is not true when
poll is used
After initialization the 8259A is set to IRR

a5498828 wrote:this isnt about PIC alone, its about searching information by myself.
So how about this nmi?

and about pic, what happens when i read port 0x20 without writing ocw3 first?
datasheet doesnt say. And its always like this. It doesnt say, i have to spam forums or test on my own wich isnt always reliable.

Improve your 'search skills'. You are interested to learn more but spend less efforts.

Hi,

a5498828 wrote:For example, yesterday ive found that port (byte) 0xA0 is an nmi port. If i write 80 its nmi disable, 00 its nmi enable, much like in port 0x70 but i dont have to read anything else, or list simply doesnt state that in case of 0xA0.

http://bochs.sourceforge.net/techspec/PORTS.LST

That says "00A0 r/w NMI mask register (XT)". The end part "(XT)" is trying to say that it only applies to an "XT", where "XT" is referring to an IBM Personal Computer XT, which is an ancestor of modern "PC compatible" computers. The old XT machines only had a master PIC (no slave PIC), and IO port 0xA0 probably was used for an NMI mask. When IBM added the second (slave) PIC chip to later PC compatible computers they probably shifted the NMI mask somewhere (e.g. to IO port 0x70) so they could recycle IO port 0xA0 for the slave PIC chip.

Most people don't care about XT anymore; and unless your OS is meant to work on ancient (8088) computers you shouldn't worry about it either.

a5498828 wrote:I also dont understand much about PIC. It has so many options... For example, eoi. There are many diffrent options for signaling eoi, bit 7-5 = 000 rotate in auto EOI mode (clear)
= 001 nonspecific EOI
= 010 no operation
= 011 specific EOI
= 100 rotate in auto EOI mode (set)
= 101 rotate on nonspecific EOI command
= 110 set priority command
= 111 rotate on specific EOI command


i dont understand them. Where should i seek help?

Or modes of operation:
bit 7-5 = 0 reserved
bit 4 = 0 no special fully-nested mode
= 1 special fully-nested mode
bit 3-2 = 0x nonbuffered mode
= 10 buffered mode/slave
= 11 buffered mode/master
bit 1 = 0 normal EOI
= 1 Auto EOI
bit 0 = 0 8085 mode
= 1 8086/8088 mode

First, the PIC chips weren't designed specifically for "PC compatible" computers - they were "general purpose" chips intended to be used in a variety of completely different computers. Because of this they supported a lot of stuff that has never been used (and has probably never worked) on PC compatible computers. In modern computers, the "PIC chips" are actually a small part of a much larger chip (e.g. a "southbridge" chip), and some of the features that the original PIC chip supported (that were useless for PC compatibles) aren't supported in modern computers at all. It is probably worthwhile to get the datasheet/s for a modern chipset and compare the information there with the information in the original PIC chip's datasheet, to get an idea of how many useless features have been ripped out.

For example, I had a look Intel's "Intel® I/O Controller Hub 10 (ICH10) Family" datasheet. For ICW4 it says that bits 5 to 7 must all be zero (reserved), bits 3 and 2 must also be zero (not used), and bit 0 must be 1. That equates to "non-buffered mode only" (because the "buffered modes" aren't supported) and "8085 mode" can't be used either. Everything else seems to be supported as described in the original "8259 Programmable Interrupt Controller" datasheet.


Cheers,

Brendan