Straight_Man
21 Sep 2003, 4:20pm
This will be as short as I can make it. To summarize, IRQs are more important than ever. To work to full effectiveness, each subsystem (or subbus) needs a unique set of resources:
IRQ, a channel of communications unique to that subbus. Subbus quick example-- USB has extreme potential, but USB is run through one of the brdige chips on all modern mobos. The bridges typically have one or two IRQs assigned to them and handle all interrupts of those IRQs.
Correllary here is that if you assign say IRQ 9(sometimes), 10, 11, or 12 to a PCI card hardware resource you by the nature of those IRQS being assigned to the bridges almost guarantee that you will have a large IRQ atack and the need for the queries to go through the bridge that is hard wired to assignment to a south bridge going to the bridge and being rerouted back to PCI every time that particular channel control query number is called. The PCI resource will limp if so assigned. The bridge assigned to the IRQs will always have to say "this is not mine," and send the signal elsewhere. This lengthens the signal path every time an IRQ is sent before a packet-- and that happens a lot.
Lets now look at IDE. IDE typically has two IRQs DEDICATED to it. 14, 15,and sometimes 13 are involved in IDE and need to be exclusive to IDE or your HD throughput will massively suffer due to other things trying to use that channel control while the hard drives or burners or DVDs are busy.
Now, IRQs 2 and 9 are also used for a special purpose. If a signal that is greater than 7 (greater than half byte size) is sent to a resource controller called an IRQ chip or circuit(actually physically a serial type chip or circuit), it passes it on to another chip designed to handle that. and pin 2 and 9 were chosen to be an IRQ forward comm circuit. This means that if 2 or 9 are used they are stacked and will be passed through that comm ciruit on the way to the end resource.
IRQs 0 and 1 are CPU and core system override IRQs, used to keep the core working when the end resources on PCI card bus, or the AGP bus, or in the case of embedded IDE or SCSI or SATA or LAN or simple core CPU need to have other resurorces (usually PCI cards or PCMCIA cards or subbus circuits that are misIRQed) overridden to let the core functions work well. And everytime you violate one of these assigned by hard design rules as above you get the CPU and core mitiagtors like bridges talking back and forth to resolve that the things they are supposed to do they cannot do because the hardware connection is not a direct one. 0 is for CPU itself, 1 and sometimes 2 are bridge overrides.
For those computers with internal modems or serial ports (not USB or SATA or LAN of non-fiber type) which are in theory serial in nature, though usually full duplex), two IRQs are used dedicated for serial unless you disable one of the COM ports in BIOS and in essence tell the system to ignore that IRQ for direction to the COMM chip.
To get a modem to work to full effectiveness if internal, it needs to be on 3 or 4 and the serial mouse if any needs to use the other of those with one of the comm ports disabled so the modem has an exclusive IRQ to function at better than 65-70% effectiveness.
To get a video card to work at full effectiveness it needs a distinct and unique IRQ unless embedded, in which case the the IRQ can be mitigated by a bridge and other things (I\O port or memory dedicated for COMM to and from video card for control signals). So, lets see what is taken out of the 16 possible IRQ signals (remember that 0 is an IRQ and is used for CPU overrideds and nothing else can use it. Soemtimes the full AGP bus is assigned to a bridge simply to have the IRQ free.
9 and up are taken, though two can be used for multiple resources via using bridge mitigation contorl as well as ID as to which bridge is mitigating for those subbuses and the use of I\O port and hardware resource IDs to send signals right and are so used in modern machines. 2 should be considered taken. The hardwired controllers for IRQ parsing do NOT parse I\O ports or device IDs in and of themselves-- the BIOS does in part supply I\O port assignment and read device IDs as it boots up and loads (subpart of invisible boot known as POST or Power On self Test, which culminates with visible screen display if IRQs are NOT radically mishmashed versus the requirements of present hardware hard coding of IRQ requirements and the BIOS locks and you get nothing or a very false or misleading beep signal or a BIOS lock signal like a siren alarm or alternating high low tones followed by silence as BIOS totally locks).
So, if you have a box sans any serial ports of trditional kinds two IRQs (or one if a builtin modem is present) are freed up for use exclusively by the PCI ro PCMCIA cardbus devices. If you have two printer ports (one usually card supported) you can occupy two more IRQs. If you have one printer port, you can use the spare IRQ for other things if the BIOS can handle the redirect properly-- PNP helps with this kind of thing but is not a total answer in and of itself, we need more busses that rely on I\O port and device ID more exclusively, like SCSI, SATA, and USB and parallel multidevice busses (which the hyperbus connects from bridges to and from CPU are one form of).
So, what is free totally for PCI card devices is:
3 and\or 4, 5 or 7 if printer present, otherwise if only USB prionters used both can be freed up by disabling parallel ports in BIOS Setup routine), 6 sometimes, and sometimes 8. And confilcts until a new way of handling interrupts in hardware is found will result in BOTH PCI card devices (or mouse and modem if both are on comm ports) giving each ohter noise and hanging each ohter as each one goes internmittently active.
That is the problem statement, we can explore the implications in the thread, but the one best way to solve is to make sure AGP and PCI have exclusive IRQs as much as possible and this often results in manual overrides of PCI slot IRQ assignments in the BIOS Setup or NOT using some slots-- PNP is made to in some cases virtualize IRQs if stacks have to be present, which is why all devices hooked to one bridge usually get one IRQ and why subusses get both I\O Ports and device IDs.
This is one reason why any one box cannot do all things equally well given present designs and one reason why both hardware and software choices need to be tied to most important use of the tool. So far, that has become something that designers have tried to handle with speed and flexibility and virtualizing handling of IRQs by using I\O ports and device ID codes and sheer speed of bus that CPU and mitigators(bridges mostly, right now) use.
I wrote this not to look like a guru, but because it is (and the implications of it) are lost on enthusiasts as it takes detailled knowledge to understand enough to realize how important IRQ uiniqueness at hard level is still needed.
Also, note that IRQs higher than 15 are virtual, and in fact are hooked to Hardware ID and I\O port and not true IRQs as used by BIOS, and the operating system gets to handle all such as BIOS is not coded to handle that so hardware or software outisde of BIOS must handle this.
John. (Please see what you can really grok (understand and recognize implications of) out of this, this issue alone can take your ssytem and make of break it or leave it limping in many ways and this is underlying part of a LOT of problems).
IRQ, a channel of communications unique to that subbus. Subbus quick example-- USB has extreme potential, but USB is run through one of the brdige chips on all modern mobos. The bridges typically have one or two IRQs assigned to them and handle all interrupts of those IRQs.
Correllary here is that if you assign say IRQ 9(sometimes), 10, 11, or 12 to a PCI card hardware resource you by the nature of those IRQS being assigned to the bridges almost guarantee that you will have a large IRQ atack and the need for the queries to go through the bridge that is hard wired to assignment to a south bridge going to the bridge and being rerouted back to PCI every time that particular channel control query number is called. The PCI resource will limp if so assigned. The bridge assigned to the IRQs will always have to say "this is not mine," and send the signal elsewhere. This lengthens the signal path every time an IRQ is sent before a packet-- and that happens a lot.
Lets now look at IDE. IDE typically has two IRQs DEDICATED to it. 14, 15,and sometimes 13 are involved in IDE and need to be exclusive to IDE or your HD throughput will massively suffer due to other things trying to use that channel control while the hard drives or burners or DVDs are busy.
Now, IRQs 2 and 9 are also used for a special purpose. If a signal that is greater than 7 (greater than half byte size) is sent to a resource controller called an IRQ chip or circuit(actually physically a serial type chip or circuit), it passes it on to another chip designed to handle that. and pin 2 and 9 were chosen to be an IRQ forward comm circuit. This means that if 2 or 9 are used they are stacked and will be passed through that comm ciruit on the way to the end resource.
IRQs 0 and 1 are CPU and core system override IRQs, used to keep the core working when the end resources on PCI card bus, or the AGP bus, or in the case of embedded IDE or SCSI or SATA or LAN or simple core CPU need to have other resurorces (usually PCI cards or PCMCIA cards or subbus circuits that are misIRQed) overridden to let the core functions work well. And everytime you violate one of these assigned by hard design rules as above you get the CPU and core mitiagtors like bridges talking back and forth to resolve that the things they are supposed to do they cannot do because the hardware connection is not a direct one. 0 is for CPU itself, 1 and sometimes 2 are bridge overrides.
For those computers with internal modems or serial ports (not USB or SATA or LAN of non-fiber type) which are in theory serial in nature, though usually full duplex), two IRQs are used dedicated for serial unless you disable one of the COM ports in BIOS and in essence tell the system to ignore that IRQ for direction to the COMM chip.
To get a modem to work to full effectiveness if internal, it needs to be on 3 or 4 and the serial mouse if any needs to use the other of those with one of the comm ports disabled so the modem has an exclusive IRQ to function at better than 65-70% effectiveness.
To get a video card to work at full effectiveness it needs a distinct and unique IRQ unless embedded, in which case the the IRQ can be mitigated by a bridge and other things (I\O port or memory dedicated for COMM to and from video card for control signals). So, lets see what is taken out of the 16 possible IRQ signals (remember that 0 is an IRQ and is used for CPU overrideds and nothing else can use it. Soemtimes the full AGP bus is assigned to a bridge simply to have the IRQ free.
9 and up are taken, though two can be used for multiple resources via using bridge mitigation contorl as well as ID as to which bridge is mitigating for those subbuses and the use of I\O port and hardware resource IDs to send signals right and are so used in modern machines. 2 should be considered taken. The hardwired controllers for IRQ parsing do NOT parse I\O ports or device IDs in and of themselves-- the BIOS does in part supply I\O port assignment and read device IDs as it boots up and loads (subpart of invisible boot known as POST or Power On self Test, which culminates with visible screen display if IRQs are NOT radically mishmashed versus the requirements of present hardware hard coding of IRQ requirements and the BIOS locks and you get nothing or a very false or misleading beep signal or a BIOS lock signal like a siren alarm or alternating high low tones followed by silence as BIOS totally locks).
So, if you have a box sans any serial ports of trditional kinds two IRQs (or one if a builtin modem is present) are freed up for use exclusively by the PCI ro PCMCIA cardbus devices. If you have two printer ports (one usually card supported) you can occupy two more IRQs. If you have one printer port, you can use the spare IRQ for other things if the BIOS can handle the redirect properly-- PNP helps with this kind of thing but is not a total answer in and of itself, we need more busses that rely on I\O port and device ID more exclusively, like SCSI, SATA, and USB and parallel multidevice busses (which the hyperbus connects from bridges to and from CPU are one form of).
So, what is free totally for PCI card devices is:
3 and\or 4, 5 or 7 if printer present, otherwise if only USB prionters used both can be freed up by disabling parallel ports in BIOS Setup routine), 6 sometimes, and sometimes 8. And confilcts until a new way of handling interrupts in hardware is found will result in BOTH PCI card devices (or mouse and modem if both are on comm ports) giving each ohter noise and hanging each ohter as each one goes internmittently active.
That is the problem statement, we can explore the implications in the thread, but the one best way to solve is to make sure AGP and PCI have exclusive IRQs as much as possible and this often results in manual overrides of PCI slot IRQ assignments in the BIOS Setup or NOT using some slots-- PNP is made to in some cases virtualize IRQs if stacks have to be present, which is why all devices hooked to one bridge usually get one IRQ and why subusses get both I\O Ports and device IDs.
This is one reason why any one box cannot do all things equally well given present designs and one reason why both hardware and software choices need to be tied to most important use of the tool. So far, that has become something that designers have tried to handle with speed and flexibility and virtualizing handling of IRQs by using I\O ports and device ID codes and sheer speed of bus that CPU and mitigators(bridges mostly, right now) use.
I wrote this not to look like a guru, but because it is (and the implications of it) are lost on enthusiasts as it takes detailled knowledge to understand enough to realize how important IRQ uiniqueness at hard level is still needed.
Also, note that IRQs higher than 15 are virtual, and in fact are hooked to Hardware ID and I\O port and not true IRQs as used by BIOS, and the operating system gets to handle all such as BIOS is not coded to handle that so hardware or software outisde of BIOS must handle this.
John. (Please see what you can really grok (understand and recognize implications of) out of this, this issue alone can take your ssytem and make of break it or leave it limping in many ways and this is underlying part of a LOT of problems).