How do I handle IRQs > 0xF ? Many PCI devices are being assigned to such IRQs (my 2 ethernet cards are IRQ 20 and 21, respectively). I can see that Windows (XP) is normally handling IRQs above 0xF. How is that done? I can also see, that 2 or more PCI devices can be attached to same IRQ (IRQ sharing) - it's described in PCI 2.1 spec. Is there any "standard" mechanism to see which device has actually sent the IRQ we handle, or it's device-specific?
The method is called IRQ Steering, read this article, http://support.microsoft.com/default.aspx?scid=kb;EN-US;q182604
hth,
Paul
hth,
Paul
Hi pbrennick,
It just says that the Windows OS "steers" a device to a particular IRQ (within 0x00 - 0x0F range) in case of a conflict. It doesn't say how am I suposed to service an IRQ higher than 0x0F. I/O PIC supports 16 IRQs (actually: 15, due to cascading), so how do I assing a CPU's 'int' to an IRQ -for example- 20?
I wouldn't be a problem if PCI devices just collided -- I would just use 'some way' to find out which one is the one sending an IRQ. But what do I do if a device says that it'll send IRQ19? And -in case of a shared IRQ (doesn't matter which one)- how am I supposed to know which device is sending IRQ? Is there any standard way, or do I have to develop some "smart ways" to find this out?
It just says that the Windows OS "steers" a device to a particular IRQ (within 0x00 - 0x0F range) in case of a conflict. It doesn't say how am I suposed to service an IRQ higher than 0x0F. I/O PIC supports 16 IRQs (actually: 15, due to cascading), so how do I assing a CPU's 'int' to an IRQ -for example- 20?
I wouldn't be a problem if PCI devices just collided -- I would just use 'some way' to find out which one is the one sending an IRQ. But what do I do if a device says that it'll send IRQ19? And -in case of a shared IRQ (doesn't matter which one)- how am I supposed to know which device is sending IRQ? Is there any standard way, or do I have to develop some "smart ways" to find this out?
> so how do I assing a CPU's 'int' to an IRQ -for example- 20?
If I understand it correctly there is still a 15 hardware IRQ lines limit for win2k and XP. But since PCI devices can share hardware IRQs one has introduced a "virtual IRQ" concept, which of course is implemented as "software".
It is handled in a software chain.
When you hook an interrupt, save the previous pointer.
If it is not your device that generated the interrupt then do a call to that previous pointer.
KetilO
When you hook an interrupt, save the previous pointer.
If it is not your device that generated the interrupt then do a call to that previous pointer.
KetilO
Hi japheth and KetilO,
So the IRQs above 0xF are virtual? But in such case: Why the actual devices report that they'll send IRQ higher than 15? They should just send -for example- 12, and leave the rest to the OS, shouldn't they?
Here: Ethernet controller config
We can read its communication config:
first I/O port: 0xB400
Address Base: 0xD3800000
IRQ: 0x15
This Ethernet controller reports that it'll send IRQ21 (0x15). How's that possible? The I/O PIC translates only IRQs in range 00-0xF into software INTs. How it's going to handle IRQ 0x15?
This quote is from Mega-Tokyo OS DEV FAQ.
It wouldn't be surprising if all PCI devices just said that they'll use IRQ12. But it IS surprising when they say, that they'll use IRQ21 :confused:
So the IRQs above 0xF are virtual? But in such case: Why the actual devices report that they'll send IRQ higher than 15? They should just send -for example- 12, and leave the rest to the OS, shouldn't they?
Here: Ethernet controller config
We can read its communication config:
first I/O port: 0xB400
Address Base: 0xD3800000
IRQ: 0x15
This Ethernet controller reports that it'll send IRQ21 (0x15). How's that possible? The I/O PIC translates only IRQs in range 00-0xF into software INTs. How it's going to handle IRQ 0x15?
There are 256 interrupts, numbered from 0 to 255, but only 16 are used by devices. These are called IRQs (Interrupt ReQuest) or hardware interrupts. The 16 IRQs are numbered from 0 to 15.
This quote is from Mega-Tokyo OS DEV FAQ.
It wouldn't be surprising if all PCI devices just said that they'll use IRQ12. But it IS surprising when they say, that they'll use IRQ21 :confused:
I am no expert with Windows, but I am guess the DDK/Docs probably state that anything above IRQ 0xF will be redirected to a valid IRQ and handled via software interrupt handlers, or just allow developers to do it without that knowledge since it doesn't make a difference as long as "it works". This might also be the reason why Windows is able to determine things so easily with virtual IRQs (what a hardware driver assigns and what Windows maps the hardware as are two different things).
As for the quote, it is more or less correct. I haven't dealt with IRQ "trickery" much, but I would follow KetilO's lead since it sounds valid for the kind of Interrupt Handling you will need.
As for the quote, it is more or less correct. I haven't dealt with IRQ "trickery" much, but I would follow KetilO's lead since it sounds valid for the kind of Interrupt Handling you will need.
This is how it is done in SolarOS also ;)
For each hardware IRQ line there is a generic handler that will check a list of registered software handlers .
Each valid software handler will get called.
This is of course slow and bad but doh this is the "standard" because each PCI board can share IRQs.
The answer from the PCI bus scanning puzzles me also.
I have also noticed this IRQ line > 0x0Fh on newer computers.
Maybe humans evolved and at last (after 10 years) some PC's have more that 15 IRQ's?
Who knows...we will have to investigate this in more details...
For each hardware IRQ line there is a generic handler that will check a list of registered software handlers .
Each valid software handler will get called.
This is of course slow and bad but doh this is the "standard" because each PCI board can share IRQs.
The answer from the PCI bus scanning puzzles me also.
I have also noticed this IRQ line > 0x0Fh on newer computers.
Maybe humans evolved and at last (after 10 years) some PC's have more that 15 IRQ's?
Who knows...we will have to investigate this in more details...
Hi SpooK and BogdanOntanu,
That quote from Mega-Tokyo is probably -at least partially- wrong. I've downloaded the Intel 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) Datasheet and gave it a quick glance. It Supports 24 IRQs (one of them is SMI#, which puts the CPU into SMM mode, so it's probably not usable). I'll proceed to play with it and learn how to identify it and program it correctly when I find some time. First thing worth the note is that there is no 'cascading' here, so IRQs 9 and 2 are separate (probably).
As for the IRQ sharing: So there is no 'standard' way to 'ask' a device if it has any data? When an interrupt occurs, I have to 'normally' check each device (assigned to this IRQ) to find out which one is the signalling one?
/edit
Quote from Intel 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) Specification Update:
The 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) may be identified by the following register contents:
That quote from Mega-Tokyo is probably -at least partially- wrong. I've downloaded the Intel 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) Datasheet and gave it a quick glance. It Supports 24 IRQs (one of them is SMI#, which puts the CPU into SMM mode, so it's probably not usable). I'll proceed to play with it and learn how to identify it and program it correctly when I find some time. First thing worth the note is that there is no 'cascading' here, so IRQs 9 and 2 are separate (probably).
As for the IRQ sharing: So there is no 'standard' way to 'ask' a device if it has any data? When an interrupt occurs, I have to 'normally' check each device (assigned to this IRQ) to find out which one is the signalling one?
/edit
Quote from Intel 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) Specification Update:
The 82093AA I/O Advanced Programmable Interrupt Controller (I/O APIC) may be identified by the following register contents:
| Register | | | APIC Offset | | | Value |
| IOAPICVER | | | 01h | | | 00170011h |
That is good news: more than 16IRQs, but they will never learn:D why not 32 or 64?
This would have fixed it for a longer time frame.
Doh, it also means that we must deal with both types of IRQ controlers in our OSes
Anyway overall this is definitively some good news.
About IRQ sharing: if you have enough IRQ lines this concept becomes a bad ideea even more!
Nevertheles it is widely used in Win2K/XP/Linux/etc since it resolves service and support problems by slowing down the PC.
And yes, unfortunately you are right there is no standard way to detect what device did trigger the IRQ.
You will have to ask each device that shares an IRQ in sequence and act acordingly. Also consider that each manufacturer has its own style and idioms and preferences. Basically you should know what IRQ'a are in a pending state and colaborate this with the information that can be extracted from the controllers; most of the time hardware controlers have a way to say: "hey, I did this!" but this way is device specific.
Take care because sometimes simply reading the controler's status ports cand trigger a state change in the device...
And maybe this device did NOT generate the IRQ but it will generate one IRQ in the future after finishing operations already launched but not finished when this "other" device triggered the IRQ :D
This would have fixed it for a longer time frame.
Doh, it also means that we must deal with both types of IRQ controlers in our OSes
Anyway overall this is definitively some good news.
About IRQ sharing: if you have enough IRQ lines this concept becomes a bad ideea even more!
Nevertheles it is widely used in Win2K/XP/Linux/etc since it resolves service and support problems by slowing down the PC.
And yes, unfortunately you are right there is no standard way to detect what device did trigger the IRQ.
You will have to ask each device that shares an IRQ in sequence and act acordingly. Also consider that each manufacturer has its own style and idioms and preferences. Basically you should know what IRQ'a are in a pending state and colaborate this with the information that can be extracted from the controllers; most of the time hardware controlers have a way to say: "hey, I did this!" but this way is device specific.
Take care because sometimes simply reading the controler's status ports cand trigger a state change in the device...
And maybe this device did NOT generate the IRQ but it will generate one IRQ in the future after finishing operations already launched but not finished when this "other" device triggered the IRQ :D
Well, the acronym "APIC" should be self-explanatory. We were simply talking about the PIC, which has had a set standard for decades already. Working with the APIC is another battle altogether, mostly an extension of the standards used in the original PIC.
The real question you have to ask yourself is, how do you make your OS work they way you want whether it is the standard PIC or the APIC???
The real question you have to ask yourself is, how do you make your OS work they way you want whether it is the standard PIC or the APIC???
That is good news: more than 16IRQs, but they will never learn:D why not 32 or 64?
I think that they just wanted to get a few really free IRQs for the PCI. Low-numbered IRQs are stuffed already with system devices and ISA devices (although no one is using them today). PCI devices can happily share IRQs, so I doubt they'll continue to increase this number (or at least: increase by some significant amount).
Doh, it also means that we must deal with both types of IRQ controlers in our OSes
That's what I thought too :P
About IRQ sharing: if you have enough IRQ lines this concept becomes a bad ideea even more!
Yeah, but it seems we're 'forced' to apply to it, since the number of devices in a regular PC i drastically growing.
And yes, unfortunately you are right there is no standard way to detect what device did trigger the IRQ.
You will have to ask each device that shares an IRQ in sequence and act acordingly. Also consider that each manufacturer has its own style and idioms and preferences. Basically you should know what IRQ'a are in a pending state and colaborate this with the information that can be extracted from the controllers; most of the time hardware controlers have a way to say: "hey, I did this!" but this way is device specific.
You will have to ask each device that shares an IRQ in sequence and act acordingly. Also consider that each manufacturer has its own style and idioms and preferences. Basically you should know what IRQ'a are in a pending state and colaborate this with the information that can be extracted from the controllers; most of the time hardware controlers have a way to say: "hey, I did this!" but this way is device specific.
There's no problem with Intel's stuff, since they document everything very, very well. ...But not everyone has Intel's chipsets. At times like this I vote for Intel's monopolization! :P
Take care because sometimes simply reading the controler's status ports cand trigger a state change in the device...
And maybe this device did NOT generate the IRQ but it will generate one IRQ in the future after finishing operations already launched but not finished when this "other" device triggered the IRQ :D
And maybe this device did NOT generate the IRQ but it will generate one IRQ in the future after finishing operations already launched but not finished when this "other" device triggered the IRQ :D
Yeah, seems like writing the Interrupt routines and programming APICs themselves is going to be very funny :P
The real question you have to ask yourself is, how do you make your OS work they way you want whether it is the standard PIC or the APIC???
Well if you ask me, then I say that I'll just support modern PCs. I'm not in mood of writing compatibility code just for 0.01% of potential users :) The OS I'm about to write already requires a Pentium-II class CPU. This will go up if I decide to use SSE throughout the kernel.
I think that they just wanted to get a few really free IRQs for the PCI. Low-numbered IRQs are stuffed already with system devices and ISA devices (although no one is using them today). PCI devices can happily share IRQs, so I doubt they'll continue to increase this number (or at least: increase by some significant amount).
The so called legacy ISA devices are in fact included in the chipset soutbridge and they are well proven, tested and pretty useful.
Even more everybody knows how to program them ;) They are not so much "not used" as they are "widely wrong judged".
This is the standard "human born yesterday sindrome"--> all that is older is bad and all there is in future is going to be good ... wake up.
A very good example is the PS/2 mouse that was there for a reason and replacing a mouse with an USB one is the most foulish ideea for multiple very clear logical reasons. Nevertheess "progress" and people did it because of miss judgement.
Even when low number IRQs are eliberated by such devices "modern" OSes like Win2k or WinXp or Linux will not "re-populate" those IRQ's but instead they will stick to sharing the same IRQ 10 or 11 :D . However Win98 was able to do this. So much for "progress"
"Happy to share IRQs" is the worst and slowest possible scenario :D The whole ideea is to try an have a single device on a single IRQ line. They will get multiplexed anyway since the CPU only has a single INTERUPT input line... now this CPU design is not the best... BUT sharing them even before the CPU is "stupidity at its best peaks"
Yeah, but it seems we're 'forced' to apply to it, since the number of devices in a regular PC i drastically growing.
I do no see how the devices in my PC that are actually using IRQ lines could grow beyond 64. Besides instrumentation for a space shuttle or cold fusion experiment. Now really in this kind of situations you would need more PC's or CPUs anyway. I would not want to delay real time data aquisitions just because I have to play "sharing IRQ line" guess games...
There's no problem with Intel's stuff, since they document everything very, very well. ...But not everyone has Intel's chipsets. At times like this I vote for Intel's monopolization! Tongue
Hihihi, YES for now Intel does that--> good for them. However do not consider Intel as playing a fair game. They just choose to do this and they could turn it OFF at any time in the future in this competition based world. Think again about NVidia and ATI that are in the same monopolistic position and refuse to offer any kind of information :D What do you do then?
Imagine a world with 99% of PC's based on INTEL chips (not hard since Apple is switching already) AND INtel witholding any new information and releasing it under mutual agreements with big player or for huge ammounts of money ...WHAT would you do then?
For example the VESA VEB /AF (acceleration) new standards are available for a "decent ammount of cash"...
Now have you seen them free on the internet lately? I also bet someone does have the NVIDIA specifications under a tight agreement.
They are not on P2P either... money and law rules!
Intel did removed the AGP 2.0 specifications from their site just to promote the NEW PCI-Express specifications for example.
Do you guess how many PC in today world stll have AGP or even PCI video cards... guess what they are exactly your test users!
I will not test a new home made OS on my new laptop (besides SolOS that is :P). I would test it on some antique slow P1 or P2 or P3 at maximum and they have very old hardware. If your OS is not runing on them :P THEN i will not give it a try anymore.
Yeah, seems like writing the Interrupt routines and programming APICs themselves is going to be very funny
Writting drivers and working with real hardware devices at low level is ALWAYS FUN ... you just need a special kind of hummor!
I have just found out that my CD-ROM reading routins that worked so nice in Virtual PC ar not working ok on slightly older CD-ROMS :P
That VESA 3.0 does NOT mean LFB is available on Intel815 integrated video board and that some devices do generate an IRQ at software reset but some others do NOT, the USB designers at INTEL did not have a CLUE what an IRQ means and what it is used for ... and the list is growing
Well if you ask me, then I say that I'll just support modern PCs. I'm not in mood of writing compatibility code just for 0.01% of potential users Smile The OS I'm about to write already requires a Pentium-II class CPU. This will go up if I decide to use SSE throughout the kernel.
Well you will be amazed to find out that more that 70% of today PCs DO NOT HAVE AN APIC (not the local one in the CPU)
So you are highly optimistic about 0.01% maybe you are refering to an 5 inch floppy drive :P
As for Pentium 2 CPU's: they clearley have no APIC as neither do most P3 chipsets.
Common confusion is created between APIC (rarely used) and ACPI (used a good deal).
A very good example is the PS/2 mouse that was there for a reason and replacing a mouse with an USB one is the most foulish ideea for multiple very clear logical reasons. Nevertheess "progress" and people did it because of miss judgement.
What's wrong with USB mice? PS/2 has a limited speed / packet rate, USB allows for higher mouse resolution. It's also pretty nice to have some of the old legacy ports removed from motherboards, since they (for many people) just take up space.
But sure, USB is "somewhat more difficult" to program than PS/2 :)
A very good example is the PS/2 mouse that was there for a reason and replacing a mouse with an USB one is the most foulish ideea for multiple very clear logical reasons. Nevertheess "progress" and people did it because of miss judgement.
What's wrong with USB mice? PS/2 has a limited speed / packet rate, USB allows for higher mouse resolution. It's also pretty nice to have some of the old legacy ports removed from motherboards, since they (for many people) just take up space.
But sure, USB is "somewhat more difficult" to program than PS/2 :)
Many things are wrong with the USB some of them are:
-very bad internal design: pooling 1024 descriptors per seccond and no real IRQ support but stil use up IRQ
-very complicated: descriptors in descriptors in descriptors but not flexible enough to have Video and mouse and stick on the same port without incredible loss of bandwidth. And evem more: please use up as much CPU power as possible for even the most simple operation.
Yes PS/2 has limits, but guess what? they are just OK for the mouse device!
I am not against using USB devices (theer are good things about it) but I consider it shuld NOT be used for the mouse.
First of all the mouse generates IRQs whan data is ready... the USB requires pooling and constant PCI bus transfers because who designed it had no clue about what an IRQ is...funny becaus the same company makes IRQ controllers (Intel)
Even more the USB mouse is a "slow" device on the USB bus and with its slow packets/mode it is slowing down other devices as well.
I think USB should be used for faster devices like sticks, HDD or video cameras.
Nope USB it is not that much more complicated to programm... it is just plain stupid...
has anyone worked on the MSI (Message Signaled Interrupt) on PCI? sounds like a fun stuff to me (at least on the name)