Re: Fighting with IRQs.
- Original Message - From: Scott Garman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 25, 2002 5:30 PM Subject: Fighting with IRQs. I would really like to learn more about how IRQ and IO assignment is done by BIOS and Linux, if anyone could point me to some good documentation. My second choice would be to get some quick enlightenment as to what I am doing wrong - it's kind of hard to decide which Ogg Vorbis quality level to encode to when I can't do my audio testing without getting beeps and clicks! :) Well, you could start by reading your Motherboard Manual's BIOS setup section. While mostly in broken English, they can contain some useful information. For example, my Award BIOS for a VIA 694X chipset lists something called Reset Configuration Data which causes all the IRQs to be reallocated on boot up by the ESCD (Extended System Configuration Data) program in the BIOS. If I were to disable this setting, I could manually assign all my IRQs based on PCI slots (or ISA slots if I had any.) If your IRQs are piling up using the ESCD BIOS assignment, try turning this feature off and manually assigning your IRQs (or at least the ones you want to force.) The way resources get allocated (very basically) is this: IF you have your PNP OS setting set to YES, the BIOS will only initialize those devices required for booting (VGA, SCSI, IDE.) The BIOS leaves the rest of the cards alone, assuming that your PnP OS will initialize them. Whether you should have this set to YES or not will depend on your specific Linux distribution. I believe the newer 2.4.x kernels do a pretty good job of allocating resources. Of course, if you have an older distro or an older (read: imperfect) implementation of the PnP BIOS, you should probably keep this disabled. If you have the Reset Configuration Data setting set to ENABLED, the BIOS will use the ESCD program to reallocate your resources on every boot. This is evidenced by the ESCD update success message you see on bootup. Normally you do not need to do this on every boot, as the cards' flash memories will retain their settings across most normal power cycles. (I think the cards reset this data and ask for configuration if they detect they have been moved to another slot, but don't quote me on that.) My motherboard manual recommends leaving this at DISABLED unless I have created a conflict that prevents booting the system. So that's what I do. :o) Then most BIOSes have a section that allows you to set the assignment of each IRQ, and sometimes the DMA channels too. The usual settings are AUTO(ESCD) and MANUAL. When resources are controlled manually, I think you need to tell the BIOS which bus (ISA OR PCI) the resource belongs to. Anything else I say at this point will fall into the realm of speculation, because I've just about exhausted my knowledge on the subject, so I'll stop here :o) Rich Cloutier President, C*O SYSTEM SUPPORT SERVICES www.sysupport.com * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Fighting with IRQs.
On 25 Jul 2002, at 1:30pm, Scott Garman wrote: I've been having a hard time trying to force my sound and network card to use different IRQs. Are they PCI cards? If so, it doesn't work that way. PCI slots each have four interrupt lines assigned to them -- INT A, B, C, and D. Those interrupt lines are connected to a component called an APIC (Advanced Programmable Interrupt Controller), which routes the PCI interrupts to the interrupt pins on the microprocessor. The routing between slots, CPUs, and APICs is entirely dependent on the particular motherboard you happen to have, and the capabilities of the APIC. In theory, none of this should matter, since PCI cards are *supposed* to be able to share interrupts. And, in general, they do so just fine. However, one does encounter non-compliant cards from time to time. Rather more often, one encounters software (drivers, kernel-level resource allocators, etc.) which cannot handle IRQ sharing. Working around such problems can range from difficult to impossible, depending on details. On bootup, my ESCD assigns most of my devices to either IRQ 10 or 11 ... ESCD = Extended System Configuration Data. The ESCD is setup by the BIOS, and includes things like IRQ mapping tables. Problems with the ESCD being incorrect are sometimes encountered, especially on early PCI systems with buggy BIOSes. so my /proc/interrupts looks like: Keep in mind that /proc/interrupts just shows what IRQs the device driver is *trying* to use. If the device driver is using the wrong IRQ, the wrong IRQ will be shown there as well. The lspci command can be useful. I've also tried assigning the IRQs via the BIOS, but that seems to do nothing either - the ESCD still piles almost everything on 10 and 11. The ESCD simply describes the system. The the BIOS, the hardware, and/or the operating system determines which IRQs get routed where. When I disable one or both of those IRQs in the BIOS, the devices won't be assigned an IRQ at all, and won't work. Most APICs are not completely flexible; they can route a particular PCI interrupt line to maybe two or three different CPU interrupt lines. I've also tried swapping cards around on physical PCI slots, which will sometimes change IRQ assignments, but as I add all of my cards (SCSI, sound, network, etc), I still end up getting IRQ pileups. That is likely the way it is going to be. If there is a PCI-to-PCI bridge in your system (and there often will be), all the slots past the bridge (moving away from the CPU) will appear on a single CPU IRQ line. I have seen systems where *all* PCI slots were wired to a *single* IRQ line. I would really like to learn more about how IRQ and IO assignment is done by BIOS and Linux, if anyone could point me to some good documentation. This is black magic. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Fighting with IRQs.
On Thu, 25 Jul 2002, at 2:00pm, Rich C wrote: If I were to disable this setting, I could manually assign all my IRQs based on PCI slots (or ISA slots if I had any.) See me other post on PCI interrupt routing. :-) ISA cards (be they legacy ISA cards or Plug-and-Play ISA cards) have all interrupt lines available to their slot. The card itself determines which of those, if any, it will use. Some cards are hard-wired to use only one; some use jumpers or switches; some are controlled via onboard logic. Before ISA PnP, it was common enough to have ISA cards which were configured using software, but each card had its own interface and program for doing so. ISA PnP simply standardizes the interface to the onboard logic which controls resource selection. If you have the Reset Configuration Data setting set to ENABLED, the BIOS will use the ESCD program to reallocate your resources on every boot. Not exactly. The cards themselves do not determine their configuration, and they need no non-volatile storage. The host computer (either the BIOS, or the OS, or some other program) gives them their configuration. Now, most BIOSes will remember PCI and PnP resource allocations between boots. The Reset Configuration Data option causes the BIOS to reconfigure all devices and rebuild the ESCD. It is a one-time option -- after the reset is performed, the Reset Configuration Data setting will switch back to Disabled. Then most BIOSes have a section that allows you to set the assignment of each IRQ, and sometimes the DMA channels too. The usual settings are AUTO(ESCD) and MANUAL. When resources are controlled manually, I think you need to tell the BIOS which bus (ISA OR PCI) the resource belongs to. Basically, if you have any non-PnP cards in your system, the BIOS (and maybe even the OS) has no way of knowing what resources they are using. The options you are talking about allow you to reserve resources for use by non-PnP cards. Using these options will cause the BIOS to *never* allocate those resources for *anything*. In theory, the OS has an advantage here, because the device driver for a non-PnP card might be able to tell the OS what resources the device is using. Or not. ISA PnP is one of those things that, when it works, it works great, and when it doesn't work, you're fscked good. :-/ -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Fighting with IRQs.
PCI slots each have four interrupt lines assigned to them -- INT A, B, C, and D. Those interrupt lines are connected to a component called an APIC (Advanced Programmable Interrupt Controller), which routes the PCI interrupts to the interrupt pins on the microprocessor. The routing between slots, CPUs, and APICs is entirely dependent on the particular motherboard you happen to have, and the capabilities of the APIC. PCI is slightly more baroque than that - a PCI card has 4 pins (int1, int2, int3 and int4) that it can use for generating interrupt requests and (IIRC) the rule is that a card is free to use no pins, but if it uses any pins then int1 must be one of them and (IIRC) int1 is considered to be primary in some respects. So much for the card; there are (as Ben said) also 4 PCI interrupt request lines (A,B,C and D) which are wired to the *slots* in a pattern that is officially known as the swizzle, being something like this: ABCD BCDA CDAB DABC ABCD . . . ...the point being that the interrupt request line that ends up being yanked by a PCI card's int1 (and int2, etc) is very much slot-dependent. Since implementation of a PCI controller is up to the vendor it's theoretically possible that some el-cheapo PCI controller could just route all 4 interrupt request lines to a single input in the Programmable Interrupt Controller (PIC), but A,B,C and D are usually routed to individual PIC inputs, thus providing *some* measure of configurability/control. So, if one request line is too busy, you might get lucky by moving the card to a different slot... Regards, Michael O'Donnell [EMAIL PROTECTED] ### # This transmission has not been approved # # by the Office of Homeland Security. # ### * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Fighting with IRQs.
- Original Message - From: [EMAIL PROTECTED] To: Greater NH Linux Users' Group [EMAIL PROTECTED] Sent: Thursday, July 25, 2002 7:24 PM Subject: Re: Fighting with IRQs. Not exactly. The cards themselves do not determine their configuration, Read my post again. I did not say that the card did this. I said that the ESCD program did (the part of the BIOS that builds the ESCD data.) and they need no non-volatile storage. The host computer (either the BIOS, or the OS, or some other program) gives them their configuration. Some cards DO keep their own configurations, although it may be only ISA cards which do this. Frequently, without a PnP BIOS to configure them, you needed a special configuration program (certain Adaptec ISA SCSI adapters do this) to set the IRQ and DMA (if applicable.) Now, most BIOSes will remember PCI and PnP resource allocations between boots. The Reset Configuration Data option causes the BIOS to reconfigure all devices and rebuild the ESCD. It is a one-time option -- after the reset is performed, the Reset Configuration Data setting will switch back to Disabled. Not true in all cases. Some BIOSes will keep the setting on Enabled, and you will see the ESCD update success... message on every boot. Rich Cloutier President, C*O SYSTEM SUPPORT SERVICES www.sysupport.com * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Fighting with IRQs.
On Thu, 25 Jul 2002, at 3:51pm, Rich C wrote: Not exactly. The cards themselves do not determine their configuration, Read my post again. I did not say that the card did this. Er, I just read your post again, and you did say that. However, you asked us not to quote you, so I won't. :-) I understood you were not clear on the matter, and I was trying to clarify things. and they need no non-volatile storage. The host computer (either the BIOS, or the OS, or some other program) gives them their configuration. Some cards DO keep their own configurations, although it may be only ISA cards which do this. Sorry, no. The context of your remark was the Reset Configuration Data setting. That setting applies to the ESCD the BIOS maintains, which is not kept on the cards. Both PCI and ISA PnP cards get the configuration from the host computer; they have no say in it themselves. (Well, that isn't strictly true; the cards can report their limitations, e.g., that only certain IRQs, DMAs, or memory ranges will work. But the host (specifically, the PnP enumerator) tells them what to actually use.) It is certianly possible for a card to keep *other* settings in NVRAM (e.g., the volume on an internal modem), but that is not what you were talking about. Frequently, without a PnP BIOS to configure them, you needed a special configuration program (certain Adaptec ISA SCSI adapters do this) to set the IRQ and DMA (if applicable.) As I said in *my* post: me Before ISA PnP, it was common enough to have ISA cards which were me configured using software, but each card had its own me interface and program for doing so. ... and ... me Basically, if you have any non-PnP cards in your system, the BIOS (and me maybe even the OS) has no way of knowing what resources they are using. So, again, that has nothing to do with the Reset Configuration Data setting. :-) Not true in all cases. Some BIOSes will keep the setting on Enabled ... Interesting. I have never seen that before. ... and you will see the ESCD update success... message on every boot. That is not necessarilly unrelated. Sometimes, the ESCD update message will always appear, even when the Reset Configuration Data is set to Disabled. I do not know if that is because the BIOS designers just felt it better to regenerate it every time, or because some piece of hardware is causing the BIOS to think it needs to, or because the BIOS is buggy, or what. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
