APIC

arDAWG

Distinguished
Dec 14, 2002
17
0
18,510
I recently set up an ABit AT7 Max mobo & came across a feature in the bios that intrigued me--APIC. On another computer w/ an MSI Pro266RU mobo I noticed that I had IRQ's from 0-19 available & I did not know why. The ABit manual & Rojak's Bios Optimization Guide (BOG) answered my question as to why this is so--APIC. Apparently, APIC is a standard to allow 2 IRQ sets for dual proc mobos, but is being implemented in newer single proc mobos for Win32 systems (2K, XP & NT). Rojak's BOG recommends enabling this for "faster & better handling of IRQs." Also, the ABit manual states that by enabling APIC it allows IRQs beyond the standard 6 PCI IRQs. On my AT7 I have 0-21 assigned. At the ABit forum I posted a question in regards to this & a d00d who claims to be a system builder responded that all my devices must be APIC compliant or I will have probs. I know that ACPI (a beast of a different stripe) requires this, but does ACPI??? I can find little info on this & my query has gone unanswered at other forums ([H]ard, Rojak's, etc). I don't know if this is b/c of no interest or, simply, b/c they don't know. I can't see a downside, other than a device compliance issue (if it is, indeed, an issue), to having more IRQ's available.
 
How's about a little discussion?

The Advanced Programmable Interrupt Controllers are definitely showing up in single-proc mainboards; it's not just for dual-proc systems anymore. On older mainboards, the IRQ controller is called a legacy 8259 PIC.

When installing Win9x, the underlying MS-DOS drivers automatically "assume" that they can write directly to the PIC controller, and can't "see" the newer APIC controller.

This means the IRQ addresses are limited to the ones directly supported by the BIOS, even if ACPI is the chosen power management type in the BIOS.

The APIC controller is a little different than the older controller. It has three parts.

The first part is a local APIC, which delivers interrupts to a specific processor. This is integrated into the processor. The second is an APIC bus, which is the delivery system for the interrupts. The third is an I/O APIC, which collects interrupt signals from I/O devices and sends messages to the local APICs via the APIC bus.

There can be more than one Interrupt Controller, because each processor in a system requires one.

32-bit operating systems like WinNT, 2K, XP and Linux support an APIC controller, which supposed allows faster and better IRQ handling. And APIC is set as the default in the BIOS, generally, when the feature is available.

APIC allows virtual IRQ addresses. Until now, all hardware was restricted to the 16 (0-15) possible IRQ addresses supported by the BIOS, with only limited support for sharing. The APIC offers 24 IRQ addresses, with ACPI enabled. It's interesting to note that a single shared IRQ address of this type in Windows allows for <i>255</i> virtual addresses when interacting with an ACPI HAL. This means a single IRQ can function as a "gateway".

However, there is a catch. TANSTAAFL, right?

1.) Some newer BIOS versions on certain mainboards with the APIC enabled can attempt to directly access and manipulate the system hardware resources. This can screw up a computer in a major way, as system board resources must NEVER be simultaneously accessed or modified by both the BIOS and the operating system at the same time. The effects can range from general instability to causing the system to stop responding completely.

2.) Access to the Programmable Interrupt Controller is always supposed to be blocked off from the BIOS in APIC mode.

3.) The BIOS blocking doesn't always work, unfortunately.

In other words, if the ACPI BIOS doesn't completely support the APIC controller, system conflicts are the result, and it may be difficult to detect the problem, as conflicts of this kind won't always show up in the Device Manager or the Event Viewer logs.

A typical response from a computer with this kind of problem is that adding <i>any</i> kind of device after Windows is installed will cause the system to be unable to identify the new device, or worse ... to shut down another device in response; typically the video card. External USB devices are particularly susceptible to causing problems of this nature ... adding something like an USB joystick or mouse can disable the video card each time the computer is restarted.

This kind of problem can also cause supposedly unrelated error messages to appear during the installation of Windows (much like trying install the OS with a bad cell in a memory chip), and most systems will finally "collapse" altogether after a few hours (or at best) a couple of days of operation, with multiple conflicts that gradually increase until the computer begins to display BSOD's, and nothing else, even in Safe Mode. I'm not "guessing" about this, either ... I've been forced to reformat several computers after having previously installed Windows with the APIC controller enabled, and I've not been able to keep any computer running for more than a month before the video card simply could not be enabled again without a reinstallation of the OS and a change of the controller type. I nursed the last system as long as possible (almost managed a month!), even after flashing the BIOS twice, and finally just gave up when the video card was halted permanently. 8-bit color isn't pretty.

Because of this, I am currently installing WinXP and Win2K on single-proc systems with the APIC controller disabled, using the older legacy 8259 PIC. If the computer already has the OS on the hard drive, once the controller is changed in the BIOS, the operating system must be repaired and/or re-installed. I prefer a fresh installation, personally.

Interestingly enough, I have only encountered this kind of issue with boards with the Intel 850 chipset. So far, nothing with a VIA, ALi or a SiS chipset, although that might change tomorrow (now that I've written this ... I have Karma issues. LOL!) And not all BIOS versions have the APIC feature ... so if a system with an 850 chipset is functioning correctly, and the APIC feature is not found in the BIOS ... I'd be hesitant about flashing the BIOS to a newer version without a very good reason, indeed.

If the controller is working correctly on your system, without causing "invisible" conflicts, consider yourself lucky, and pat yourself on the back.

At the ABit forum I posted a question in regards to this & a d00d who claims to be a system builder responded that all my devices must be APIC compliant or I will have probs. I know that ACPI (a beast of a different stripe) requires this, but does ACPI???
It's true that the devices must be ACPI-compliant, but that in itself is necessary to run an ACPI HAL without problems. Of course, with the older APM HAL, the APIC controller wouldn't be functional in the first place. You only get the virtual IRQ address sharing if both ACPI and the APIC are enabled at the same time. But from the way you worded this, I'd have to assume that the fellow on the forum was a bit confused, as I have never heard of devices being <i>APIC</i>-compliant. Just ACPI-compliant.

Most folks see APIC, and think it was just ACPI spelled incorrectly. Figures, huh? <GRIN>

Toey

<font color=red>First Rig:</font color=red> <A HREF="http://www.anandtech.com/mysystemrig.html?rigid=17935" target="_new"><font color=green>Toejam31's Devastating Dalek Destroyer</font color=green></A>
<font color=red>Second Rig:</font color=red> <A HREF="http://www.anandtech.com/mysystemrig.html?rigid=15942" target="_new"><font color=green>Toey's Dynamite DDR Duron</font color=green></A>
________________________________________

<A HREF="http://www.btvillarin.com/phpBB/index.php" target="_new"><b><font color=purple>BTVILLARIN.com</font color=purple></b></A> - <i><font color=orange>A better place to be</font color=orange></i>. :wink:
 
Hey, Drake ... what's shakin'? :wink:

I've been helping my mother take care of my 92-year-old grandmother, who fell recently and broke a hip. After the surgery, unfortunately, she had a massive stroke. Keeping her fed, clean, and getting involved in the physical therapy has been taking up most of my days and evenings whenever I'm not biting the bullet at work. But I sure miss hanging out here, and at BT's site ... hopefully, I'll be able to find some time in the future to get back into the swing of things.

See ya!

Toey

<font color=red>First Rig:</font color=red> <A HREF="http://www.anandtech.com/mysystemrig.html?rigid=17935" target="_new"><font color=green>Toejam31's Devastating Dalek Destroyer</font color=green></A>
<font color=red>Second Rig:</font color=red> <A HREF="http://www.anandtech.com/mysystemrig.html?rigid=15942" target="_new"><font color=green>Toey's Dynamite DDR Duron</font color=green></A>
________________________________________

<A HREF="http://www.btvillarin.com/phpBB/index.php" target="_new"><b><font color=purple>BTVILLARIN.com</font color=purple></b></A> - <i><font color=orange>A better place to be</font color=orange></i>. :wink:
 
TYVM...I've posted this in several forums (as I have noted) & gotten many different answers. Ur's, by far, is the most in depth. I get the feeling that this is kinda unchartered territory for many (myself included, as I could ferret out little on the subject--a rarity on the web). I've had no probs, I can attribute directly to APIC, as of yet, but I have added no new devices either. The ABit AT7 is really doing well..I can boot into & run Win XP Pro w/ the fsb @ 166 (mem & cpu). I running a 1.4 Tbird in this sytem w/ Crucial pc2100. I am planning a major system redo in the near future, as I plan to add 2 60-80gb hdd's running in raid 0 on the Highpoint 372 controller. I will prolly disable APIC when I do this. I wuz all giddy over finding this feature w/ all the new IRQ's, but after studying the assignments ACPI is still bunching them up anywayz. I may have more IRQ's opened up, but in the end they're still sharing despite APIC (e.g., the onboard Lan & the ATI 8500 are sharing IRQ 16, whereas w/ APIC disabled it wuz IRQ 11). So, in reality I'm right bak where I started...lmfao.
 

TRENDING THREADS