We ended last month with the introduction of a system that was, at least theoretically, going to solve all system resource allocation problems, Plug and Play. This rapidly became known as Plug and Pray, since it didn't always work, and was somehow programmed to know when timing was critical (as with scheduled implementation dates) so as to fail to work properly in just those situations (at least it seems that way to me).

One of the key concepts of Plug and Play is that IRQs (Interrupt Requests) can be shared. This means that you could end up with more than one board assigned to the same IRQ. In practice, this often, though not always worked. Boards do not always play nice and share their toys.

Note that features imbedded into motherboards could use system resources, not just added boards in expansion slots. IDE, floppy and sometimes SCSI controllers, sound and video circuits, and I/O ports (serial, parallel, and USB) may be imbedded in modern motherboards, all demanding the previously discussed system resources.

Now we fast forward to the present to see a nasty trend that is making life difficult for system integrators. That is the tendency by motherboard manufacturers to get so paternalistic about things like system resources that we are insulated from the process so that there are no easy ways for us to manually assign them. Plug and Play isn't so bad to work with if there is some logical way to override IRQs as necessary. Without that ability, things can get very messy. It's like driving a car with mandatory cruise control and no real accelerator.

So, there I was trying to configure a NetWare 6 server with a high-end Intel motherboard specifically designed to be in a specialized server. I go to the CMOS Setup page associated with assigning IRQs and find a row of fixed "logical" IRQ numbers on the left side of the screen and a row of menus for assigning "real" IRQ numbers on the right. There are no instructions. The manual contains only a blurred screen shot of this page with no additional information. Intel's Web site (www.intel.com) has tons of documents related to this motherboard, but nothing on IRQ assignments.

I contacted the computer manufacturer and they didn't have any information on IRQ usage with this motherboard. They were kind enough to contact Intel directly and came back with the following "facts" from Intel tech support:

1. IRQs, in general, don't matter, so don't bother yourself worrying about them.

2. Shared IRQs don't exact any performance penalty, even in a server.

3. IRQ order doesn't matter since they are all the same priority.

4. NetWare has never supported Plug and Play, so IRQs really don't matter with NetWare, anyway.

6. With Windows-based servers, IRQs don't matter.

5. There is no way on this motherboard to assign IRQs to specific boards and/or embedded circuits.

As to item 1, I can only think, could they be even more paternalistic and condescending? It reminds me of the old line that was, (and probably still occasionally is) used on women, "Don't worry your pretty little head about such things." Note that there was no excuse offered for not documenting this page.

For items 2 and 3, I direct you to the Adaptec Web site, www.adaptec.com, or, for that matter, to any add-on board manufacturer's Web site. You will find a plethora of documents relating to the criticality of performance optimization in servers by the proper allocation of IRQs, specifically by avoiding shared IRQs for critical devices like disk controllers and network cards, and by assigning devices based on the numerical priority inherent in IRQs. (The priority order is usually listed as 0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7. 2 is for cascading to 9 and is not available and 8, the real-time clock, also considered not really available, is sometimes listed as last.)

For items 4 and 5, I direct you to the Novell and Microsoft Web sites, www.novell.com and www.microsoft.com, for even more info on the importance of manually assigning server IRQs using the setup routines in motherboards to avoid both compatibility and performance issues. Additionally, I will note that Novell uses Plug and Play information from individual devices while not actually supporting the motherboard-centric aspects of the standard. It has done this at least as far back as NetWare 4.1. That's how its semiautomatic configuration and setup routines work.

Item 6 is where the Connection comes in. The IRQ setup screen reminded me of a magic trick that I learned as a child. In it, you spread out cards in columns. Then you have the subject mentally select a card and tell you which column it is in. You then gather the cards and spread them out in rows and ask what row the chosen card is in. Depending upon the number of cards involved, the pattern continues until you "magically" announce the subject's chosen card (to thundering applause, no doubt). Actually, this is a simple mathematical game of elimination. By noting the series of answers from the subject, you can figure out the chosen card.

Back to the present, again, I used a version of this magic trick on the motherboard. To prepare, I first discarded any IRQ that I knew I didn't want to use, and freed up any that I could spare. NetWare likes to keep IRQ 15 to itself, so I disabled the unneeded secondary IDE controller that uses it. I wasn't using COM1, COM2, or LPT1, so I disabled them and freed up IRQs 4, 3, and 5, respectively. Then I assigned all of the desirable IRQs in numeric order from top to bottom repeating as necessary to cover all of the logical IRQs and rebooted.

Some cards will tell you their IRQs, but you may have to rely on either the operating system or a utility program to determine other IRQ assignments. I frequently use a DOS-based utility, EMDIAG, from Adaptec. It is available as part of early versions of the driver files for their 4-port network cards. There are other utilities available if you look on the Web.

I wrote down the possible logical IRQs for each of the cards or circuits I was analyzing, based on their reported real IRQs. Then I reassigned the real IRQs on the setup page in a different order. Using logic here can reduce the number of iterations needed to solve this puzzle. I rebooted and recorded the results. This led me to reduce the possibilities on my written list of boards and circuits. Based on this I reassigned the IRQs and again rebooted. This time I was able to reduce the possible IRQs associated with each board or circuit to one, thereby solving the problem.

Now that I knew which board or circuit was associated with which logical IRQ, I could assign real IRQs as necessary for maximum performance and compatibility. It's magic! (Wait here for thundering applause.) And I did it without encountering those pesky fire ants.