Interrupt/routing tables, where are they?

[SkaarjMaster]

Assigned PCI interrupt tables, IRQ routing tables, interrupt pin assignment tables, whatever they're called they are pretty scarce lately. I know these days that there is less of a concern about assigned IRQs and stuff because of XP, but why don't motherboard manufacturers include this information in their manuals. I know Asus and a few others included this in the past, but I don't see much of this anymore. The old viahardware site (now sudhian) has some old ones for some older Abit and Shuttle boards, but how do I find the Assigned PCI Interrupt Tables/IRQ Routing Tables for the newer motherboards? I've checked some motherboard sites with no luck. Thanks for any help on this matter.

 

[Peter]

It's because it doesn't matter at all. IRQ sharing is a ridiculously overhyped non-issue, being a mandatory part of PCI specification ever since (at least) PCI 2.0 which first appeared in 1993.

But if you desperately WANT to know, use a utility program that reads out the PIC and APIC (not ACPI!) routing tables for you. For the former, browse the web for Craig Hart's PCI diagnostics tool. This is a DOS program, and when invoked with /P switch, also decodes the PIC IRQ routing table for you.
Reading the APIC routing table is a tad more complicated, I have not seen a public tool for this yet.

 

[SkaarjMaster]

Yes, i want to know, but before I buy the motherboards. You see depending on the chipset or motherboard, the interrupts may be different. With video and sound cards taking up more than one slot these days, it could become an issue. That's why I would like to know ahead of time. Thanks for any more info. you can provide.

 

[SkaarjMaster]

Well, I just found out that Soyo has this "PCI IRQ Assignment" table (Soyo's term for it) in their manuals of their newer motherboards for download at their web site. Anyone know about any of the other manufacturers?

 

[Peter]

Read my lips: Shared IRQs are not an "issue". They never were. In fact, they are a fully intended design feature of PCI and AGP busses.

You and all the other IRQ fetishists are beating a dead horse.

 

[SkaarjMaster]

Peter, that's all good and well, but why not try and get everything on it's own IRQ as much as possible anyway (that's what I like to do and I'll try it again with XP in about 6 months with my new system). Let's see someone try to run a graphics intensive video game with their AGP video card and PCI sound card on the same IRQ; there will be issues one way or another. As far as shared IRQs never being an issue, where have you been for the past 5 years? Stoned?! Anyway, you have your views and I have mine, so let's leave it at that. Anyone else know about where to find these tables for other MB manufacturers besides Soyo?

 

[Peter]

No, I've been designing PC mainboards. Nuff said.

 

[SkaarjMaster]

That's all fine and dandy Mr. Board Designer God, but being asleep for the past 5 years you obviously have been oblivious to the fact that numerous people have had IRQ sharing problems. Whether you have any secrets or not to get around the issue or are just referring to the XP operating system, you cannot escape the fact that this has been an issue in the past, continues to be an issue and will continue to be an issue in the future. Now, apparently, XP and some motherboard designs have done a lot to minimize this issue, but it still exists. Yes, it is a bit overhyped, but it remains an issue. Anyone else that wants to jump in this thread, please feel free.

All I was asking for was access to PCI IRQ Assignment tables and I get bashed by someone who is obviously clueless to the IRQ issue. It's people like you that ruin the forum experience. Why don't you go bash some other thread a**hole!

 

[Peter]

No, sorry, I'm in touch with customers (and our customer support) well enough to have learnt that every and all perceived "IRQ sharing problems" boiled down to being mere crap driver problems. This is particularly true in the sound department, Creative standing out as the prime producer of drivers with messy interrupt handlers.
With properly written drivers, I've seen as many as 20 devices of all kinds mangled onto one IRQ, system working fine. (Our boards aren't the usual kind, we have up to seven onboard devices and up to 14 slots, all of which can carry multiple PCI devices.)
I know that stuff from the inside.

Now since you've chosen to continue insulting me rather than listen, I'll be off this thread. Moderators shall be informed.

 

[DieHardware]

Originally posted by: SkaarjMaster
That's all fine and dandy Mr. Board Designer God, but being asleep for the past 5 years you obviously have been oblivious to the fact that numerous people have had IRQ sharing problems. Whether you have any secrets or not to get around the issue or are just referring to the XP operating system, you cannot escape the fact that this has been an issue in the past, continues to be an issue and will continue to be an issue in the future. Now, apparently, XP and some motherboard designs have done a lot to minimize this issue, but it still exists. Yes, it is a bit overhyped, but it remains an issue. Anyone else that wants to jump in this thread, please feel free.

All I was asking for was access to PCI IRQ Assignment tables and I get bashed by someone who is obviously clueless to the IRQ issue. It's people like you that ruin the forum experience. Why don't you go bash some other thread a**hole!

SkaarjMaster you are the weakest link, goodbye and good riddance.

 

[SkaarjMaster]

Bye Peter. Bye DieHardware. It's really a shame the response I got in this forum in this thread from close minded people. I've gotten such a better response from other forums. I thought Anandtech was a decent forum, but I guess I was mistaken.

 

[KF]

Not that I have experience with large numbers of mobos, but I agree with Peter that people think this is more important than it is. For years, I deliberately violated the rules that the scuttlebutt claims should cause problems to see if I could cause a problem, and failed. It is true though that some persistent, unsolvable problems magically disappear when you reshuffle the PCI cards. Rarely. But it is so easy that it is worth a shot. Yes this is a driver problem, but we are always glad to solve a problem in whatever way one can.

I'm not sure what kind of tables you are looking for, but I think what you are interested in is which PCI slots have identical interrupts. I have rarely seen this in mobo manuals. Obviously if you swap cards between slots that have an IDENTICAL hardware structure, you are spinning your wheels.

FWIW, this is what I have learned from noodling in BIOSes and reading some specs on the Internet:

First, not all mobos/chipsets, locate on-board things on the PCI bus. They may or may not. For instance, serial ports, parallel ports, sound, midi, LAN. These get assigned interrupts, which may be unchangeable, or limited to a few choices, regardless of what goes on with the PCI bus.

Many things (like the floppy controller, real time clock, and numerical processor) get an interrupt, aside from anything the PCI bus gets, using up almost all the hardware interrupts.

What is left over, if anything, can be assigned to the PCI bus. (You can have more than one PCI bus, but I never saw that myself). These PCI bus interrupts are 4 in number, and designated A, B, C, and D. If there are only three interrupts left to be assigned, them at least 2 of the slots will get the same A interrupt. You could even have them all get the same interrupt. Every PCI card may use all 4 of the interrupts, not just A, if the designer/engineer chooses. The only thing different about the interrupts of the 4 distinct PCI slots is which interrupt is designated A.

For the sake of simplictity suppose the PCI bus is set up so that
slot1 gets
A=1 B=2 C=3 D=4
then slot2 gets
A=2 B=3 C=4 D=1
In other words, the interrupts are rotated from slot to slot. They actually use the same interrupts.

There used to be 16 interrupts (or 15, depending on how you think about it) on a standard IBM clone, which is what we all think of as PC style computer. This was a result of the original IBM PC using Intel's PIC (Programmable Interrupt Controller) chip having 8 interrupt pins, plus Intel's optional cascading scheme that hooks a second PIC to one interrupt on the first. There have not been actual PIC chips on mobos for years and years. It is all located somewhere on a tiny part of the chipset. Recent chipsets/BIOSes have an option to expand the number of interrupts by chosing APIC (Advanced Programmable etc.) From looking at the interrupt list, there must be at least 32. I don't know if these are real hardware, or something done in software.

BIOSes now include something called ACPI. (Advanced Control and Power Interface?) This started out as something to put the computer into several low-power modes. It has been expanded into a _processor_ _independant_ BIOS. By using ACPI, you are supposed to be able to control all of the mobos hardware. If the computer conforms to ACPI, you can do this on a Mac, a PC, a SPARC, whatever. XP is said to use ACPI for setting up hardware and operating it, including interrupts. As far as I can tell, the upshot of this is that interrupts are "redirected" within ACPI, so that just because an interrupt has a certain designation (1 to 32, say) in XPs Device Manager does not mean the sound card actually gets that interrupt. What the numbers represent is which software device handler will get the interrupt when ACPI delivers an interrupt to the OS. In a protected mode OS like Windows, the interrupts ALWAYs go to the OS first, before they go to the device handler anyway. The OS can always choose to ignore it, do something else, or pass control to the device handler.

Windows 98 in the later stages got drivers (at least from VIA) that appear to use this ACPI redirection scheme.

How does the 32 interrupt APIC mode going through ACPI to the 4 PCI interrupts really sort out? I don't know.

There is usually a section in the BIOS to designate interrupts to "legacy" things. Frequently there is a section to designate something about the interrupts for PCI. Don't get your hopes up. This is for DOS and the initial boot process. Windows can, and usually does, reorder everything after it gets control. However, choices in the BIOS may affect how Window ends up reordering things.

If everthing is perfectly clear, then I must not have explained it properly Just realize that the designers have long ago taken away direct control from the user.

 

[SkaarjMaster]

KF, the voice of reason. Thanks for your input, my faith in AnandTech has been restored!

 

[Peter]

Right so far. Only that chipsets do not per se have four PCI interrupt lines - in fact it's anywhere between 1 and over 100 (!). Mainboard designers are free to choose what lines to use for what, and the choice is arbitrary anyhow since it makes no difference other than electrical properties. The only given is what lines are used by chipset internal devices.

ACPI is a better interface between BIOS and operating system, and enables the OS to know and see things only BIOS knew in previous software architectures. It doesn't change the way interrupt signalling works at all. Outside DOSish environments, interrupt request handlers are always the property of the operating system, who then dispatches to device drivers registered for that vector.

Now what DOES change it is the appearance of APIC interrupt controllers in newer systems. Here, every PCI interrupt input is a separate, dedicated event, signalled to the CPU without the help of the ancient PIC interrupt controllers. This is faster, by eliminating the PIC interrupt signalling as the slowest link - but you still get interrupt line sharing in loaded systems, even if you are on an E7501 chipset with 104 interrupt lines. The number of APIC interrupt lines depends on the chipset's implementation - you always have 16 inputs for the legacy IRQs, and then as many PCI IRQ inputs as the chipset implements, again, from 1 to over 100.

So KF, it's the other way round. The PCI IRQs go directly into the APIC(s), who signal them to the CPU(s). There isn't any programmable routing in that at all.

As long as you're not running APIC mode, all the PCI IRQ lines are routed back to the legacy PICs, and pile up on the usual 15 IRQs. THIS is programmable.

 

[hatboy]

I don't have as much knowledge about specifically how interrupt controllers work as Peter or KF, but I can say that I've seen the debate about whether or not IRQ sharing is an issue many times over the last several years. It usually goes much like the conversation between Peter and SkaarjMaster. Somebody says something like device x and y don't work together when they share an IRQ. Somebody else then says almost exactly what Peter did, saying that IRQ sharing has been a part of PCI for 10 years, so it can't possibly be an issue.

From my experience building and working on PCs, I know one simple fact about interrupt sharing: devices work correctly more often when they are not sharing interrupts. That is simply a fact and I've seen too many problems related to IRQ sharing for anyone to convince me that it is not true. If the motherboard guy wants to blame it on crappy drivers for peripherals, fine. If peripheral makers want to blame it on crappy motherboards, fine. The fact is, for whatever reason and no matter what the nice documents defining PCI and AGP say, IRQ sharing, for whatever reason, sometimes does not work well with some devices. I think, then, that if you're building a PC, there's no reason not to try to avoid sharing IRQs. Certainly, your devices might all work fine even if they are on the same IRQ. But from my experience, your devices are MORE LIKELY to work if they are on separate interrupts.

One final thought: I've got a PCI PowerMac from 1995 that I run Linux on. It has 32 interrupts, and all devices always get their own unique IRQ. I've never had any issues with PCI cards only working in certain slots, which certainly can't be said for most of my PCs. I suppose with things like APICs and ACPI, the x86 world is catching up in terms of interrupts, but it seems a little late in coming.

 

[DieHardware]

Peter with most of the MB I've used there's a switch allowing the BIOS to be set to APIC or ACPI. Which is the better way to go with a modern OS like WinXP or Redhat9?

 

[Peter]

It isn't APIC _or_ ACPI. You can have ACPI interface with or without having APIC interrupt controllers, and vice versa.
Modern OSes are definitely better in controlling the system when the ACPI software interface is present. General performance is better when the operating system uses the APICs rather than the old PICs. Windows NT and its offsprings as well as Linux can, DOSy Windows flavors can't, but they don't care when APICs are present - they just don't kick the system into APIC mode and keep using the PICs.

 

[Peter]

hatboy, the point is, as a card or mainboard designer, you can't do it electrically wrong. With the operating system then catching the actual interrupt trigger and despatching to the individual drivers, all that remains as a possible cause of interrupt related problems is the drivers.
Now these then are still nothing to do with whether a certain IRQ vector is shared or not - it's rather whether a higher priority interrupt is holding the system for too long, sabotaging stuff on lower priority vectors.
Random card shuffling stunts might or might not shift a card with a problematic driver onto a lower priority vector - that's all you do. Sure it does mask the symptoms w/o updating questionable drivers, but only until the next hardware item is added that reshuffles the routing, and only as long as the system is not using the APIC interrupt controllers. And it's not an IRQ sharing thing either - it's an IRQ prioritization thing, it's about whether the badly behaved drivers are on a high or low priority line. (On the PICs, the priority chain is 0-1-8-9-10-11-12-13-14-15-3-4-5-6-7, high to low.)

When you're on the APICs, which any HT enabled P4 or other SMP system MUST have and use (and which also must be used by MS's standards on uniprocessor systems whose chipsets happen to have APIC hardware), there is no prioritization by the IRQ input line anymore at all. Card shuffling tricks simply don't work on these anymore at all.

So you folks better learn the proper technique for building working systems: If a card misbehaves, check for driver updates, if none, return to sender and use someone else's.

 

[SkaarjMaster]

I just want to say one more thing. The fact remains that if you have a problem and you change the IRQs and the problem goes away, then it appears to be an IRQ issue and it was solved. We do have control over this, but not the drivers without switching out equipment. This is what it boils down to whether an IRQ or driver problem.

Peter, I do understand where you're coming from though now that you've explained it a little more. Thanks for the input!

 

[Peter]

You're welcome, and thanks for not playing foul anymore.

The main point in why this all is rather pointless is: Practically all systems today run APIC mode, in which card shuffling does nothing and IRQs aren't routed anymore. You just HAVE to put up with using hardware whose drivers are well written. For an end user, the only way to put pressure on a vendor is to stop buying their stuff. For every piece of hardware out there known to have poorly written drivers (do I hear Creative?), there are well working alternatives.