OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:34 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: PIC spurious interrupts and I/O APIC
PostPosted: Tue Jan 01, 2008 9:51 pm 
Offline
Member
Member
User avatar

Joined: Wed Nov 17, 2004 12:00 am
Posts: 202
Location: Germany
hi,

As I found out PIC spurious interrupts also occur when all irqs in the PIC are masked. So my question is whether they are also signaled when I am in I/O APIC mode, because the only things required to go there is mask all irqs in the PIC (and possibly write to the ICMR). The problem is, if this is not sufficient, then I would have to disable the interrupt lines the PIC is connected to, which could be an ExtInt in the I/O APIC or a LINT0/1 of a Local APIC, right?

Thanks in advance!

_________________
lightOS


Top
 Profile  
 
 Post subject: Re: PIC spurious interrupts and I/O APIC
PostPosted: Wed Jan 02, 2008 4:19 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

bluecode wrote:
As I found out PIC spurious interrupts also occur when all irqs in the PIC are masked.


Spurious interrupts are typically used to resolve race conditions in hardware. For example, if your code disables interrupts in the CPU (CLI instruction), then an IRQ occurs, then the PIC tells the CPU an IRQ occured, then your code masks the IRQ in the PIC, then your code enables interrupts in the CPU (STI instruction), then the CPU asks the PIC to send an interrupt vector, then the PIC doesn't know what to send because the IRQ is now masked so it sends a spurious interrupt to keep the CPU happy.

To prevent these race conditions you'd need to do things in a different order - leave interrupts enabled in the CPU, then mask all IRQs in the PIC, then have a small delay to let any pending IRQs be handled, then disable interrupts in the CPU if you can think of a reason to bother.

I have heard rumours that noisy interrupt lines can also cause spurious interrupts, but I've never seen it happen in practice (and can't confirm or deny the rumour)...

bluecode wrote:
So my question is whether they are also signaled when I am in I/O APIC mode, because the only things required to go there is mask all irqs in the PIC (and possibly write to the ICMR).

The problem is, if this is not sufficient, then I would have to disable the interrupt lines the PIC is connected to, which could be an ExtInt in the I/O APIC or a LINT0/1 of a Local APIC, right?


Disabling the ExtINT entries (in the I/O APIC and/or local APICs) should work in theory. For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: PIC spurious interrupts and I/O APIC
PostPosted: Wed Jan 02, 2008 6:14 am 
Offline
Member
Member
User avatar

Joined: Wed Nov 17, 2004 12:00 am
Posts: 202
Location: Germany
Thanks for clearing up the spurious interrupt thing :)

Brendan wrote:
For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...

Do they have the same interrupt vector in APIC mode as without all the APIC foo, e.g. if I remapped the PIC to 0x20 and 0x28, will the spurious interrupts still be 0x27 and 0x2F in APIC mode?

Another not so related question: How do you handle bochs/qemu PCI interrupts? Because they are mapped to the ISA interrupts (edge-triggered vs. level-triggered). Are the PCI I/O Interrupt Assignments supposed to be like an override of what's in the PCI config space in the Interrupt field? Does the interrupt line field (INTA, INTB, ...) in the PCI config space matter at all?

Thanks in advance!

_________________
lightOS


Top
 Profile  
 
 Post subject: Re: PIC spurious interrupts and I/O APIC
PostPosted: Thu Jan 03, 2008 7:36 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

bluecode wrote:
Brendan wrote:
For my OS, I'd be more comfortable if the spurious IRQs from the PIC are actually handled as spurious IRQs instead of being ignored though...

Do they have the same interrupt vector in APIC mode as without all the APIC foo, e.g. if I remapped the PIC to 0x20 and 0x28, will the spurious interrupts still be 0x27 and 0x2F in APIC mode?


Yes.

bluecode wrote:
Another not so related question: How do you handle bochs/qemu PCI interrupts? Because they are mapped to the ISA interrupts (edge-triggered vs. level-triggered). Are the PCI I/O Interrupt Assignments supposed to be like an override of what's in the PCI config space in the Interrupt field? Does the interrupt line field (INTA, INTB, ...) in the PCI config space matter at all?


The interrupt pin field in PCI config space is hardwired, and indicates which interrupt line the PCI device/function uses (A, B, C or D). This is mostly meaningless, as you don't know how the interrupt lines at the card (or at the PCI slot) are connected to interrupt lines at the PCI host controller or how they're routed from the PCI host controller to the PIC chips or I/O APICs.

During boot the BIOS looks at the interrupt pin field and (using motherboard specific knowledge) sets the interrupt line field, which is (from the PCI device's point of view) just a read/write field that is unused by the hardware (and could be set to anything without making any difference). The BIOS sets the interrupt line field to the PIC input number that the PCI IRQ happens to be routed to during boot, so that an OS (that doesn't use APICs) can find out which PIC IRQ each device/function is using.

For PCI devices/functions, the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables are used to find out which I/O APIC input each PCI device/function uses.

For Bochs (and any rare and obsolete real computers that have "Pentium era" I/O APIC IRQ handling), the "I/O Interrupt Assignment Entries" (used for I/O APIC inputs) will probably match the values in the interrupt line field in PCI configuration space (used for PIC inputs) because the PICs and the I/O APIC will probably be wired identically.

For modern computers the PICs and the I/O APIC won't be wired identically - the IRQs connected to the APICs will be connected to different inputs (e.g. input 16 to input 20) and won't be connected to the I/O APIC via. the ELCR or PCI IRQ router, so the "I/O Interrupt Assignment Entries" (used for I/O APIC inputs) probably won't match the values in the interrupt line field in PCI configuration space (used for PIC inputs).

Basically, for the rare and obsolete "Pentium era" I/O APIC IRQ handling (used by Bochs and Qemu) I program the I/O APIC according to how the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables tell me to program them; and for modern computers I program the I/O APIC according to how the "I/O Interrupt Assignment Entries" in Intel's Multi-Processor Specification tables tell me to program them... ;)

This makes it fairly simple - it's just a pity it all turns into an over-complicated puddle of hot sticky vomit once you try to use ACPI... :cry:


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 65 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group