Slashdot Mirror
ACPI Forced On & Option Disabled in WinXP-Certified Motherboards
stealth_zipper asks: "I just got off the phone with a rep from Soyo Computer Inc trying to get the ability to change IRQs for the onboard hardware. It turns out that because of a deal to get WindowsXP certification, the Dragon-series motherboard ended up having the ability of Enabling/Disabling ACPI in the BIOS disabled. Now FreeBSD has complications with multiple devices on the same IRQs (especially sound, video, and nic all off the same one). Is there a way to get around this for new hardware? Has anyone else encountered this?" Why in the world does XP need this feature disabled, and are there workarounds to get OSes like FreeBSD working properly with motherboards of this sort?
Learn the basics of ACPI, and some more, at acpi.info, webopedia, and Microsoft
-
Because ACPI is deprecated, in favour of APM. Is that a good enough reason? God forbid we should actually move forward and embrace new standards.
Good try, but in fact the reverse is true: APM is deprecated, and ACPI is the new standard.Some of the things that Microsoft has forced us to change in the past few years include:
- One of our main products was in full compliance with the IEEE
specification for the USB interface. However, because Windows 2000 used a
while() loop for a timing operation, it was sometimes flaky when dealing
with our product. As a result, we needed to re-engineer an ASIC (this was
damn expensive) to make it compatible. The original version, of
couse, was fully compatible with Linux.
- Normally Windows communicates in a little-endian fashion. However, for
two particular device status operations, Windows inexplicably violates yet
another published spec and forces the device into big-endian (mac fag)
mode. We needed to change firmware to fix this, and delay the release of
our product by 3 weeks.
- Microsoft required that the source code to our Windows drivers got
audited in order for the product to be approved. Hmm, why don't they let
us audit their code?
Naturally, though, since the DoJ has dropped the ball on Microsoft, this sort of thing will only get worse. Get used to it, and vote Democratic in 2004.Bill
Sir, you have misinterpreted the information suggested on that [cknow.com] link. APM was superceeded by ACPI. ACPI defines a wider range of power and system status related functions. There is an interpreter, and the ACPI spec is well defined.
SIGERR: laziness exceeds quota
I've been running stably for over sic months on an overclocked Athlon Dragon board. I'm currently running XP, though i have also run Mandrake and Win2k. Were it not for the KT266 chipset, I would consider this a damn near perfect board.
Opinions are not Informative, though they may be Insightful or Interesting.
If you read the article it says "It turns out that because of a deal to get WindowsXP certification, the Dragon-series motherboard ended up having the ability of Enabling/Disabling ACPI in the BIOS disabled."
This means that ACPI is always ON, not off.
Hey I agree totally. The boards have great specs... tons of cool features... nice documentation... the whole bit.
They just have a HIGH failure rate.
You got lucky =)
-kwishot
In the shortest way I can explain it, changing ACPI from on to off or vice versa on a current install of Windows 2000 or XP will... "fuck shit up." A more detailed description of how/why "shit gets fucked up" follows:
In Windows, peripheral component interconnect (PCI) devices can share IRQs. In accord with the Plug and Play capability that is defined by the PCI specification, adapters are configured by the computer BIOS and are then examined by the operating system and changed if necessary. It is normal behavior for PCI devices to have IRQs shared among them, especially on Advanced Configuration and Power Interface (ACPI) computers that have Windows ACPI support enabled.
In Windows XP, Device Manager may list some or all of the devices on your ACPI motherboard as using the same IRQ (IRQ 9). (To view the list of resources, click either Resources by type or Resources by connection on the View menu). No option is available to change the IRQ setting. Windows takes advantage of the ACPI features of the motherboard, including advanced PCI sharing. The PCI bus uses IRQ 9 for IRQ steering. This feature lets you add more devices without generating IRQ conflicts.
Note that Windows XP cannot rebalance resources in the same way that Microsoft Windows 98 does. After PCI resources are set, they generally cannot be changed. If you change to an invalid IRQ setting or I/O range for the bus that a device is on, Windows XP cannot compensate by rebalancing the resource that was assigned to that bus.
Windows XP does not have this ability because of the more complex hardware schemas that Windows XP is designed to support. Windows 98 does not have to support IOAPICs, multiple root PCI buses, multiple-processor systems, and so on. When you are dealing with these hardware schemas, rebalancing becomes risky and therefore is not implemented in Windows XP except for very specific scenarios. However, PCI devices are required to be able to share IRQs. In general, the ability to share IRQs does not prevent any hardware from working.
The Plug and Play operating system settings in the computer BIOS do not generally affect how Windows XP handles the hardware. However, Microsoft recommends that you set the Plug and Play operating system setting to No or Disabled in the computer BIOS. For information about viewing or modifying the computer BIOS settings, consult the computer documentation or contact the computer manufacturer.
Manually assigning IRQs to PCI slots in the system BIOS as a troubleshooting method may work on some non-ACPI systems that use a standard PC hardware abstraction layer (HAL), but these settings are ignored by Plug and Play in Windows if ACPI support is enabled. If you need to manually assign IRQ addresses through the BIOS to a device on an ACPI motherboard, you must reinstall Windows to force the installation to use a Standard PC HAL. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
More info can be found he'a...
First of all, ACPI was created to a) make computers that "boot" instantly by always being in sleep mode and b) end the IRQ conflicts so common with earlier versions of Windows and hardware. So yes, ACPI, when working right, simply rocks.
However, ACPI on certain motherboards, especially AMD motherboards, can cause severe system instability with Windows 2000 and Windows XP. (Please note that these OSes don't freeze/BSOD under normal circumstances, so if you're seeing this, you probably have a hardware issue which could be related to ACPI.)
The most common scenario I have seen is this:
-- Someone decently technically savvy builds his/her own PC with an AMD chip;
-- Said person installs Windows XP;
-- Said person wonders why IRQs are all set to 9;
-- Said person goes and manually messes with IRQ settings, thus wreaking havoc on the poor commputer that functioned perfectly before.
It can also go the other way:
-- Said person installs Windows XP with AMD chip;
-- Said person experiences weird freezes;
-- Said person's computer works fine with Windows 98 because Win98 doesn't have full ACPI support, so person is left wondering why everyone says that Windows 2000 and Windows XP are so stable since that person's computer crashes constantly.
To turn off ACPI, reinstall Windows and set your computer type to "Standard PC." Here is an excellent guide on how to set your PC to a Standard PC. As mentioned in the guide, this gives you the added benefit of increased framerates in Quake 3. However, you have to manually turn your computer off, and it might not go into powersave mode properly. Here is another comment regarding ACPI.
So, to summarize:
-- If you're having problems with Windows 2000/XP freezing, try this fix. Freezes are indicative of a hardware issue. Your computer should be stable with these OSes (except for application crashes, which happen with every OS.) My current uptime with Windows 2000 is 27 days; I have seen over 100 days uptime. If you're not seeing this type of stability with 2000/XP, it's time to do some hardware diagnostics.
-- If you're not having problems, leave well enough alone and leave ACPI turned on.
-- Do NOT mess with your IRQs on an ACPI computer! By messing with IRQs manually, you're asking for weird system problems. Leave them all on 9 -- it won't hurt the computer.
-- Due to the problems mentioned above, I personally will not buy AMD chips and motherboards. I have yet to see ACPI problems crop up on an Intel motherboard. It's unfortunate, because I like AMD and like to encourage competition, but their chips and motherboards have strange issues that have yet to be resolved.
I hope this helps all of you who are having problems with Windows XP or 2000.
Simpli - Your source for San Jose dedicated servers and colocation!
Reboot the computer, go into the bios, see if you can 'reserve' IRQs. if you can, mark them ISA - that'll stop them from getting assigned to windows or OS. Then just reboot .... disabling the PNP features forces them to be reserved. As long as the OS can still talk to it, it'll be just fine.
You raise a good point. I have an Abit KG7 motherboard, which also has ACPI enabled with no option to turn it off in the BIOS (because "they needed it that way to get Microsoft certified").
I dual boot Gentoo Linux and Windows 2000, and I just happened to be in Windows one day when I got a BSOD for an ACPI error. I thought my motherboard was bad, so I sent it back. When I got the replacement and tried to re-install Windows, I got the same BSOD. It turns out that it was a faulty DDR memory stick.
To the submitter of this story: Swap out ALL hardware before deciding something is bad. Had I done this, it would have saved me 3 weeks of grief.
My Abit KT7-RAID had the option hidden as well, and it wasn't until I enabled it so that I could turn off ACPI that my system finally got stable, even with win2k. I found Paul's KT7 FAQ invaluable. Specifically this item.
most of this post was clipped from a MS site
it sounds to me more like "we didn't want to solve a hard problem so we made the problem space smaller".
If a device only generates an interrupt every second or two, but the CPU takes 500mSec to service that interrupt, that means that everything else using that IRQ is left out in the cold for that time. (This is the Interrupt Latency)... even a 1Ghz P4 won't be able to play sound without breaking up if this happens... which is just plain stupid.
Video, Network, and Disk devices obviously have different requirements and should each have their own interrupt. This insane sharing of IRQs should end.
--Mike--
You can get a "tweaked" bios that adds the ACPI on/off feature again. I got one for my KG7-RAID to fix some quirky hardware issues. Check www.biosmods.com Then, get a floppy disk, reboot, flash, and you're all set to go.* I found a great wealth of info (even for non-abit owners) at Paul's KG7FAQ
*Flashing the BIOS can be risky for the inexperienced. Don't lose power! (how?).
This was posted by an MS guy to the OSR NTDEV listserv:
The early ACPI machines were mostly laptops. And the laptops of that generation had most of their devices either embedded in the chipset or on the ISA bus. The PCI or AGP buses were used only for video, and to connect the north bridge with the south bridge. (In Intel's chipset terms, the North bridge has all the fast gates of the chipset, including the memory controller, AGP and in that generation, the PCI bus generation logic. The south bridge contains all the slow gates, including the IDE controller, the ISA bridge, all the PC legacy stuff and probably a USB controller. Today, the south bridge probably also has audio and a few other random odds and ends.) Because the laptops of that era had all of their devices on the ISA bus, interrupt sharing worked poorly. If you bought a mid-'90s laptop from IBM or Toshiba, the serial port and possibly IR would be disabled. There would be a utility packaged 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 the PCMCIA slots, since there just weren't enough IRQs in the machine to guarantee that all of the peripherals worked, especially if you filled both PCMCIA slots with combo cards.
I once debugged a Toshiba 750CDT in a docking station that had two PCMCIA cards plugged into the machine, two PCMCIA cards plugged into the slots in dock, two ISA cards in the dock and an extra IDE device in the dock, 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 interrupt controllers, which would allow many more IRQs, in their laptop chipsets since 1997. My predecessor had been trying since '94. They may actually manage it soon.)
Along comes ACPI. When you turn on ACPI in a machine, it suddenly switches all the power management logic in the machine from delivering its interrupts as BIOS-visible, non-vectored System Management Interrupts over to OS-visible, vectored interrupts. And that interrupt is delivered level-triggered, active-low, which means that it can be shared with a PCI interrupt.
Now consider that these early ACPI machines were already over-committed in terms of interrupts. There was no way to make them work with PCI devices spread out on lots of IRQs. So I just made the code collapse all the sharable devices onto the ACPI interrupt, which was fixed in the chipset by Intel at IRQ 9. By doing it this way, I could hide the fact that ACPI had just created a demand for one more IRQ. (If you use a non-Intel chipset that has ACPI coming in on some other IRQ, you'll see all the PCI devices in Win2K go to that IRQ, not 9.)
Further complicating this story was that I was trying to get ACPI machines to work back in 1997, when the people working on Plug and Play in Win2K hadn't yet gotten their stuff going yet. At time, it wasn't possible to move a device from one set of resources to another after it had been started. This meant that any IRQ solution that I came up with had 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, as long as none of the device drivers mis-handled their ISRs. (Later, this turned out to be a huge debugging problem, since when you chain eight or nine devices, you'll get somebody who fails.) The solution wasn't optimal, 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-processor problems and on other aspects of ACPI. It got close to the time to ship Windows 2000 and somebody brought up the old question of IRQ stacking. I worked up a more-elegant solution, one that spread out interrupts on most 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 that they wouldn't let me put it into the product, since they didn't have time to re-test the thousands of machines that had already been tested with the old algorithm.
At the time, I thought that this was somewhat ridiculous. I thought that my code would work just fine. I thought that their fears were un-justified. But I was overruled, and I just put the code into what became Windows XP, letting Windows 2000 ship with the simple, safe, yet frustrating stacking.
This is a good point in the story to explain that, in ACPI machines, the IRQ steering is accomplished by interpreting BIOS-supplied P-code called ASL. The IRQ routers are completely abstracted by the BIOS. The OS doesn't need to know about the actual hardware. The old IRQ steering code in Win9x, which was dropped into the non-ACPI HAL in Win2K, had to have code specific to each chipset, which meant that it didn't work when new chipsets were shipped. It was also written in a way that it assumed that there were exactly four IRQs coming from PCI. ACPI machines sometimes have many more. (This is the reason that you don't see the IRQ steering tab in ACPI machines. It just wasn't flexible enough and we didn't have time to re-do it.)
What we discovered with Windows XP was that all of those ACPI machines that had been tested with their IRQs stacked on IRQ 9 tended to fail when you spread the IRQs out. A typical example of a failure would work like this: WinXP doesn't need the IRQ for the parallel port unless you're using one of the extended modes. So the parallel driver releases its IRQ until it's needed. The IRQ choosing logic (called an IRQ "arbiter") would move a PCI device onto the parallel IRQ. This action depends on re-programming the chipset so that the parallel port isn't actually triggering the IRQ. This is supposed to happen by interpreting even more BIOS P-code that manipulates the chipset, since there is no standard for parallel port configuration.
If your chipset comes from Intel, this probably works, since the mere act of setting a PCI device to an IRQ also disconnects that IRQ from the ISA bus. But if your chipset comes from VIA or ALi, there is another step involved. The problem is that nearly all of the BIOS P-code out there is copied from old Intel example code. So they are almost all missing the extra step necessary in VIA and ALi machines.
If the BIOS fails to stop the IRQ coming from the parallel port, the machine hangs, since the parallel port, which sends its IRQs active-high, edge-triggered, will ground the interrupt signal in the passive 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 the legacy SuperIO chip and the story repeats itself.
In Windows XP, I made a bunch of changes. In machines without cardbus controllers, (which don't have the IRQ problems created by PCMCIA,) it will try to keep the PCI devices on the IRQs that the BIOS used during boot. 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 know to be broken, then we fall back to the Win2K-style stacking behavior. The unfortunate truth is that you guys on this list mostly build your own machines, rather than buying them from reputable manufacturers, which means that you guys own the machines with broken BIOSes and VIA chipsets. So even with WindowsXP, you'll see the same old stacking behavior.
One notable addendum is that any machine with an APIC interrupt controller, and thus more than 16 IRQs, will spread interrupts out, even in Win2K. In the past, this was mostly limited to SMP machines. But any desktop machine shipping today that gets the Windows logo has to have an APIC. (This was another reason that I hadn't gone back to re-write this code earlier. Intel had promised that all machines would have APICs by 1998. If this had materialized, then none of you would have had any complaints by now.) I'm actually currently working on software for some future NT that will let an administrator configure the
machine in any way he or she desires.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Probably too late for an AC to be moderated up, but what the hell...
I learned how this stuff works by running into problems using VMware. If you install XP on a system with ACPI enabled, then try to run it on one with ACPI disabled (such as VMware, which supports APM but not ACPI) it won't boot. The problem is that XP (and 2000 & NT) uses a different HAL for ACPI support. Its easy enough to fix (search www.vmware.com for ACPI & HAL if you care)
I don't know about Microsoft's claims WRT XP not supporting APM, but there is at least some APM support in there, because if you install XP inside a VMware virtual machine, and tell the VM to use APM, you can get XP to power off on shutdown. Maybe some of the other APM stuff doesn't work, dunno.
Each PCI bus (yes there can be many more than one) supports up to four interrupts. The way the bus is wired, these interrupt lines are equally distributed among the slots. Actually, all slots have the four lines connected, they are just staggered to the devices, so that the first interrupt line in slot 0 is not the first interrupt line again until slot 4, but each slot can actually use all four interrupts, most devices use one. The PCI bridge is then given four IRQ numbers to assign to those lines, in the case of Windows 2000 and XP its 9 for all the lines. Not a big deal, because you may be sharing already and this is the way the PCI bus is suppose to be able to work, in an ideal world.
The problems come about in the drivers and in design. When devices share interrupts, drivers need to be conservative about what they do in their ISR's (interrupt service routines) because someone else on that same interrupt might be trying to get some work done too, (like playing a wave file through your sound card and transfering data thourgh you fire wire card at the same time) both cards will be producing interrupts that need to be serviced. Its difficult to write efficient interrupt handlers for many reasons, but not impossible. People usually get lazy or the hardware is poorly designed. And that's why there are so many problems with sharing interrupts. In theory it should work, but the drivers/hardware are sometimes not up to the task.
Microsoft has said, this is how we are going to do it, its designed to work like this, make your devices work right. Although, they can be dicks when it comes to their hardware certification program (WHQL), the devices should be able to work like this. Now as far as the MoBo, my guess is that it probably did not function correctly in non-ACPI mode, and MSFT said, fine ACPI works, but if you go into non-ACPI mode, we can't certify you....
"Karma can only be portioned out by the cosmos." -Homer Simpson
Maybe this Abit trick for a similar 'disable hidden' problem will work with Soyo boards?
Here's the link (12th item down):
http://www.viahardware.com/faq/kt7/faqbios.html
Slashdot: rejecting tech news in favor of rubber band guns since 1997.
wrong! win2k has a different HAL with an ACPI kernel to one without! you cant just 'change' modes.
see here
You cannot change between Standard and ACPI HALs because of the different way an ACPI and a non-ACPI BIOS enumerate hardware. The copy of the hardware tree, which is kept in the registry, is stored differently for each type of HAL. If you change the HAL without running Setup again, Windows may not be able to find hardware components needed to start the computer.
no sig for you
I don't think this is actually entirely Microsoft's fault. A *lot* of motherboards appear to have ACPI problems with Windows XP, which I gather is being quite strict in it's adherance to ACPI specs, where as some of the motherboard chipset vendors have not been so diligent. That said, I have a motherboard which is "not 100% ACPI compliant" according to the vendor which is running Windows XP fine in ACPI mode, so it looks like a classic "YMMV" issue.
UNIX? They're not even circumcised! Savages!
I don't know the ins and outs of the whole issue - I do know that according to ABIT, Msft didn't let them pass with their KT7 board or any of their newer boards.
I owned one -- and tried to disable ACPI on it. I called abit because I couldn't find a setting in the BIOS for it, and they said that to be Msft certified you couldn't include it.
They pointed me to this BIOS editor to be able to edit the choices in my BIOS and re-enable the option. --from Paul's unofficial ABIT MOBO Page: (I know it sounds shady, but check it out if you don't think it's legit..):
"None of the new Abit BIOS versions support the disabling of ACPI through the BIOS, as this functionality has been hidden. This is because this is a prerequisite for any mainboard submitted for Microsoft WHQL approval."
Where are you getting your information that Microsoft is OK with disabling ACPI? IMHO, Microsoft and open *anything* don't get along very well..
"I do not fear computers. I fear lack of them." -Isaac Asimov
As a former MS employee (contract) in WHQL (Windows Hardware Quality Labs) I know a lot about what is required to get a logo.
First off.. nobody is required to get a Windows Logo.
However it is a good marketing tool. It's nice for your customer to see the neato little sticker on your product. It is only a sticker.
ACPI is hard to get right.
I have seen hundreds of boards get sent back to the manufacturer because they failed a wake from S3. Or a timed wake from S3. Or because they weren't throttling the processor properly. Or a thousand other things that can go wrong with ACPI.
Apparently Soyo is sucking at getting it right.
If Soyo's implementation of ACPI is flawed it would be perfectly reasonable for them to either turn it off 100% of the time... or turn it on %100% of the time (although off is way more likely)
If they don't have ACPI enabled... it can't be wrong can it?
That's the general principle. If you can't get it right... don't include it, you'll only shoot yourself in the foot.
For those of you interested, you can purchase the WHQL driver qualification CD on the Microsoft website. It's nifty. Also I made it.
Remember the main idea here is that the primary cause of blue screens isn't the windows kernel. It's bad drivers. The real reason behind the windows logo program is to attempt to force people to have decent drivers. So if you want your Windows Logo... your drivers had better not suck.
Name ommitted for obvious NDA related reasons... although all of the info above is common knowledge... and prolly posted on Microsoft's web site.
It seems like Soyo probably has a problem with there board and is using this MS thing to cover it up (maybe this board mis-malbehaves when ACPI is disabled; and as such they always have it enabled). It seems like this WinXP thing is a red-herring of sorts.
no, if you followed the link, you would of read that in order to be certified, ACPI must be enabled, always.
The Kruger Dunning explains most post on
The specification that dictates that users cannot disable ACPI support in BIOS is PC2001, the PC Design Guide specification. Their website (http://www.pcdesignguide.org/) appears to be down right now. Dell has a pretty informative whitepaper on the subject.
0 1- pc2001.htm
... FreeBSD doesn't have ACPI support and Linux has poor ACPI support. The IRQ sharing problem should be handled by the OS. Changing IRQs in the BIOS is a workaround for bardhardware or bad software. FreeBSD will just ignore the ACPI configuration information and use traditional methods to configure the hardware.
http://www.dell.com/us/en/gen/topics/vectors_20
PC2001 is an industry specification. It's been around for a while and was open to review by a number of large computer companies. ACPI is an open spec (confusing as hell, but open) which has been around for four years now.
The motherboards manufacturers have to conform to PC2001 if they want the "made for Windows" sticker.
Here's the real issue
IRQ sharing is very common in today's hardware and should be supported by the OS. If the hardware owner sees one piece of software work and another fail, they will blame the bad software.
The point of hibernate is that if your laptop has about 5 minutes worth of juice left it can write the RAM to HD and turn the whole computer off without loosing anything you were working on.
Context would indicate that you did not actually mean to talk about letting loose or releasing data that you were working on. Rather, I believe you were talking about failing to retain data. The word you were looking for is losing.
Congratulations! You have been participant #48 in my campaign to rid Slashdot of this error.
Proudly correcting Slashdot's most irritating linguistic error since 2002.
Because if the Dells in the world sell just 1 motherboard thats not XP certified they loose there MS discounts and they wont be able to compete.
I doubt that Dell would ever voluntarily let loose or release their MS discounts. Of course, it is entirely possible that Dell would fail to retain them. Consequently, I believe the word you were looking for is lose.
Congratulations! You have been participant #49 in my campaign to rid Slashdot of this error.
Proudly correcting Slashdot's most irritating linguistic error since 2002.