This is a stupid story. And I'm embarrassed to tell you the truth. Buthere it is.The early ACPI machines were mostly laptops. And the laptops of thatgeneration had most of their devices either embedded in the chipset oron the ISA bus. The PCI or AGP buses were used only for video, and toconnect the north bridge with the south bridge. (In Intel's chipsetterms, the North bridge has all the fast gates of the chipset, includingthe memory controller, AGP and in that generation, the PCI busgeneration logic. The south bridge contains all the slow gates,including the IDE controller, the ISA bridge, all the PC legacy stuffand probably a USB controller. Today, the south bridge probably alsohas audio and a few other random odds and ends.) Because the laptops ofthat era had all of their devices on the ISA bus, interrupt sharingworked poorly. If you bought a mid-'90s laptop from IBM or Toshiba, theserial port and possibly IR would be disabled. There would be a utilitypackaged with the machine that allowed you to turn on your serial or IR,but at the cost of the bi-directional parallel port, or one of thePCMCIA slots, since there just weren't enough IRQs in the machine toguarantee that all of the peripherals worked, especially if you filledboth PCMCIA slots with combo cards.I once debugged a Toshiba 750CDT in a docking station that had twoPCMCIA cards plugged into the machine, two PCMCIA cards plugged into theslots in dock, two ISA cards in the dock and an extra IDE device in thedock, too. This meant that the total demand on the machine was 20 IRQs,when only 16 were actually available.(As an aside, I've been trying to convince Intel to put APIC interruptcontrollers, which would allow many more IRQs, in their laptop chipsetssince 1997. My predecessor had been trying since '94. They mayactually manage it soon.)Along comes ACPI. When you turn on ACPI in a machine, it suddenlyswitches all the power management logic in the machine from deliveringits interrupts as BIOS-visible, non-vectored System ManagementInterrupts over to OS-visible, vectored interrupts. And that interruptis delivered level-triggered, active-low, which means that it can beshared with a PCI interrupt.Now consider that these early ACPI machines were already over-committedin terms of interrupts. There was no way to make them work with PCIdevices spread out on lots of IRQs. So I just made the code collapseall the sharable devices onto the ACPI interrupt, which was fixed in thechipset by Intel at IRQ 9. By doing it this way, I could hide the factthat ACPI had just created a demand for one more IRQ. (If you use anon-Intel chipset that has ACPI coming in on some other IRQ, you'll seeall the PCI devices in Win2K go to that IRQ, not 9.)Further complicating this story was that I was trying to get ACPImachines to work back in 1997, when the people working on Plug and Playin Win2K hadn't yet gotten their stuff going yet. At time, it wasn'tpossible to move a device from one set of resources to another after ithad been started. This meant that any IRQ solution that I came up withhad to work from the first try, so it had to be conservative.The everything-on-IRQ-9 solution worked. It got the machines to run, aslong as none of the device drivers mis-handled their ISRs. (Later, thisturned out to be a huge debugging problem, since when you chain eight ornine devices, you'll get somebody who fails.) The solution wasn'toptimal, but it did work. I meant to go back and change it later,before we shipped Windows 2000.A couple of years passed. I had been working on multi-processorproblems and on other aspects of ACPI. It got close to the time to shipWindows 2000 and somebody brought up the old question of IRQ stacking.I worked up a more-elegant solution, one that spread out interrupts onmost machines. By that time, Plug and Play had been mostly completed,and that wasn't a bottleneck any more. But the test team told me thatthey wouldn't let me put it into the product, since they didn't havetime to re-test the thousands of machines that had already been testedwith the old algorithm.At the time, I thought that this was somewhat ridiculous. I thoughtthat my code would work just fine. I thought that their fears wereun-justified. But I was overruled, and I just put the code into whatbecame Windows XP, letting Windows 2000 ship with the simple, safe, yetfrustrating stacking.This is a good point in the story to explain that, in ACPI machines, theIRQ steering is accomplished by interpreting BIOS-supplied P-code calledASL. The IRQ routers are completely abstracted by the BIOS. The OSdoesn't need to know about the actual hardware. The old IRQ steeringcode in Win9x, which was dropped into the non-ACPI HAL in Win2K, had tohave code specific to each chipset, which meant that it didn't work whennew chipsets were shipped. It was also written in a way that it assumedthat there were exactly four IRQs coming from PCI. ACPI machinessometimes have many more. (This is the reason that you don't see theIRQ steering tab in ACPI machines. It just wasn't flexible enough andwe didn't have time to re-do it.)What we discovered with Windows XP was that all of those ACPI machinesthat had been tested with their IRQs stacked on IRQ 9 tended to failwhen you spread the IRQs out. A typical example of a failure would worklike this: WinXP doesn't need the IRQ for the parallel port unlessyou're using one of the extended modes. So the parallel driver releasesits IRQ until it's needed. The IRQ choosing logic (called an IRQ"arbiter") would move a PCI device onto the parallel IRQ. This actiondepends on re-programming the chipset so that the parallel port isn'tactually triggering the IRQ. This is supposed to happen by interpretingeven more BIOS P-code that manipulates the chipset, since there is nostandard for parallel port configuration.If your chipset comes from Intel, this probably works, since the mereact of setting a PCI device to an IRQ also disconnects that IRQ from theISA bus. But if your chipset comes from VIA or ALi, there is anotherstep involved. The problem is that nearly all of the BIOS P-code outthere is copied from old Intel example code. So they are almost allmissing the extra step necessary in VIA and ALi machines.If the BIOS fails to stop the IRQ coming from the parallel port, themachine hangs, since the parallel port, which sends its IRQsactive-high, edge-triggered, will ground the interrupt signal in thepassive state. And grounding an interrupt which is enabled active-low,level-triggered will cause an endless stream of interrupts.The parallel port is just an example. Pick any device that is in thelegacy SuperIO chip and the story repeats itself.In Windows XP, I made a bunch of changes. In machines without cardbuscontrollers, (which don't have the IRQ problems created by PCMCIA,) itwill try to keep the PCI devices on the IRQs that the BIOS used duringboot. If the BIOS didn't set the device up, then any IRQ may be chosen.But if your machine has a VIA chipset, or if it has a BIOS that we knowto be broken, then we fall back to the Win2K-style stacking behavior.The unfortunate truth is that you guys on this list mostly build yourown machines, rather than buying them from reputable manufacturers,which means that you guys own the machines with broken BIOSes and VIAchipsets. So even with WindowsXP, you'll see the same old stackingbehavior.One notable addendum is that any machine with an APIC interruptcontroller, and thus more than 16 IRQs, will spread interrupts out, evenin Win2K. In the past, this was mostly limited to SMP machines. Butany desktop machine shipping today that gets the Windows logo has tohave an APIC. (This was another reason that I hadn't gone back tore-write this code earlier. Intel had promised that all machines wouldhave APICs by 1998. If this had materialized, then none of you wouldhave had any complaints by now.) I'm actually currently working onsoftware for some future NT that will let an administrator configure themachine in any way he or she desires.- Jake-----Original Message-----Subject: Re: Communicating with the NT developersFrom: "Maxim S. Shatskih" < [email protected] Date: Thu, 27 Dec 2001 18:22:20 +0300X-Message-Number: 19Hi Jake,>expertise. (For those who are curious, I have spent the last fiveyears>working on the NT HAL, with lots of forays into power management and>ACPI.Then maybe you're exactly the person who will be able to answer to oneof the popular questions here:- why ACPI HAL puts all PCI cards to IRQ9? What were the technicalbackgrounds of such a decision? Why PCI IRQ steering is allowedfor non-ACPI HAL (and even has a UI property sheet) and is disabled onACPI?thanks,Max---You are currently subscribed to ntdev as: $subst('Recip.EmailAddr')To unsubscribe send a blank email to leave-ntdev-$subst('Recip.MemberIDChar')@lists.osr.com