IRQs in an interdynamic system
Straight_Man
Geeky, in my own wayNaples, FL Icrontian
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).
0
Comments
Whew.. It's fun to be a geek again.
First, it is multiple packet per wave cycle capable. Second, it is a way of extending the full front side bus used in the CPU to the bridges and in some cases giving the bridges a wider bus path than the more peripheral busses have. Speed and trhoughput, while still needing IRQs for each bridge for the "legacy" destination determination circuitry.
ACPI is more a way of using things OTHER than primarily IRQ to address peripherals and peripheral (outside of the morem modern extended FSB) and a way to tell them to sleep when not needed (power management and more flexible distinct device addressing), and some good info is here:
http://www.acpi.info/
AC is Advanced Controller, PI is Power Interface. It is a way fo combining both the old APM and simultaneoiusly movign away from primarily IRQ channel uses and will eventually REPLACE IRQs as it must for intercompatibility with more hardware. This will let windows choose its internal control codes independent of BIOS, and let BIOS take care of hooking device ID to device. Device IDs themselves are moving to more than 3 byte codes in triplets(ACPI3) or doublets (ACPI 2 and to a degree ACPI 1 which for the most part got replaced by 2 before lots of use in the consumer market), which leaves lots of room for uniqueness. These codes are often now not HEX, they are often OCTAL base in non-windows operating systems. 4044:4210:1432 has unique meaning to modern BIOSs as to major bus, minor bus, and device custom hooks and lots of the reason for 2 MB single BIOSs is reference tables of what codes go what bus for the bus\subbus hooks. ACPI3 is not in the marketbase yet, it won't be until mfrs use it and that is probably a year away or more (I think ACPI3 is one thing we might see at least a large start to support in software at O\S level in Longhorn).
Yes, you are right and the info flow is staggering to knwo about these things and stay ahead of them. Problem is when that move is made, lots of legacy stuff will just plain be useless as its firmware is intended for IRQ, ACPI, and APM compatibility.
Parallel only printers will need to be replaced, many older COM port things will be utterly useless as they will NOT be able to keep up throughput with USB rates at all and thus even adapting will only be possible with lots of RAM buffering on the cards that adapt(thing like USB<->print buffer<->parallel printer inline devices will be needed to use Parallel dot matrix and parallel only printers made to work much slower than modern USB printers as far as data flow goes, and there will be a revolution in peripherals that is just starting to hit home to many. With higher speed busses, I think serial will have a chance in things like USB and SATA rate flows.
Parallel busses will be used for supercomputing and server clustering internal to servers more and more, as SCSI and SANS and NAS appliances are coming into their own now.
They probably will be replaced inside of boxes by very fast serial-primarily busses with very flexible addressing that is BIOS compliant and eventually bridge compliant as I expect soem of the control functions to go to the bridges as we see Silicon on Insulator and TRIistors(similar to Thyristors but with one input and more than one output at transistor level) more commonly used. Expect, in a decade or two, trinary to be more common than binary as tristate and trigate transistors replace traditional two gate transistors now(I am talking output option gates, not just In and out). Expect the pace NOT to degrade in this one regard. And for anything regarding large scale use of optical computing, or neural nets, multibranching is a requirement at the base level.
The O\Ss have to move now to be able to meet the pace that is upon us. ACPI ii and iii ARE steps on that path, just as IPV6 is gonna be neded to handel the burgeoning amounts of private websites and blogs and personal pages even as to GETTING THERE(addressing). For IPV6, think more than 6 octets per node address in an IPV6 capable network, and 4-5 levels of network in a WAN possible.
IDIC requires more flexible and larger data uniquenesses for device IDs to be able to delegate more and more onto the board subparts with fewer and fewer conflicts. Then the CPUs can be less and less pre-emptors and more and more focused on purer computations with vector calcs getting a very large advantage from the lack of pre-emption required timeslices.
John.
NS
At least, that's my understanding.