ACPI Forced On & Option Disabled in WinXP-Certified Motherboards 556
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?
wouldn't this (Score:5, Insightful)
microsoft makes so many smart moves.
Re:wouldn't this (Score:3, Insightful)
but it looks from available comments that these are just shitty mobos. choice is not a problem; BIOSen are better for having enable/disable options, not worse. if mobos are being crippled to meet MSFT demands, that's different, and foolish, tho so far Bill's gang hasn't suffered at all for having contempt for the legal system or their customers.
why is this (Score:2, Interesting)
The other side of it is that it causes issues with BSD, a non-GPL OS. One of the OSs MS actually shows some support for. Why does THIS make sense?
Further, I think it may demonstate a more insidious strategy for MS. The HW is configured in such a way that alternative OSs cannot use it. That's bad, that's very very bad. This could SEVERELY limit where Linux/BSD can be used.
OTOH, companies like IBM and other motherboard manf may come out with Linux-only lines and find a nice little niche market there...
Comment removed (Score:5, Interesting)
Re:why is this (Score:4, Informative)
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 [viahardware.com] 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 [viahardware.com] 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..
Re:why is this (Score:3, Informative)
no, if you followed the link, you would of read that in order to be certified, ACPI must be enabled, always.
Re:wouldn't this (Score:4, Insightful)
The DOJ is consistantly taking an extremely narrow view. Any issue that wasn't raised before trial, or was dropped from the case, or was not proven at trial, or hampered in any way by the appellate verdict is not open for remedy in the settlement. Nor will they do more than the minimum to ensure competition - even if it is very limited competition. (For example multi-million dollar RAND is ok because megacorps can then compete. It doesn't matter that GPL and indviduals are completely blocked from competing.) Compatability certifacation is completely voluntary and therefore does not prevent competition.
I do not believe "Windows Compatibility Certifacation" was ever raised as a concern at trial. Therefore the DOJ won't even look at it.
On the otherhand the states that are still persuing the case might be quite interested.
-
Re:wouldn't this (Score:3, Informative)
Soyo Dragon (Score:5, Insightful)
I work at a computer shop in Wisconsin and we've gone so far as to stop carrying them because of the problems.
DOA.... bad slots.... bad ps/2 ports... "nothing after POST"... you name it.
I'd just make sure that it's ACPI causing the problem and not a defective board.
-kwishot
Re:Soyo Dragon (Score:2, Informative)
Re:Soyo Dragon (Score:2, Informative)
They just have a HIGH failure rate.
You got lucky =)
-kwishot
Re:Soyo Dragon (Score:4, Informative)
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.
Re:Soyo Dragon (Score:5, Interesting)
(woh, did I mix enough metaphors for ya?
Soyo has come out with some rather good boards, and some rather bad boards. Asus and Abit also have come out with some rather craptacular boards.
Hell who knows it may just be one faulty little part that once it is found everybody will be going "Duh!" and slapping their hand against their forehead.
Disabling ACPI does suck though.
Especially since anybody who is going to go into the BIOS setup screen and change that sort of settings (which requires reinstalling Windows, at least on 2000 it does, so it is NOT something that you just go ahead and do without a thought for it) aaah screw it.
Basically Win2k (and I am extrapolating for XP here, since it is awfully simular... ) required two separate kernels, one for ACPI, one without ACPI.
I am sure that MS was just getting friggin annoyed with having to support two kernels, not to mention run support for two completely different ways of doing the IRQ thang (WTF is up with backwards support and IRQs? Current x86 OSs support the old way of IRQs to work with current motherboards, current motherboards support it to work with current OSs, WHAT THE FUCK IS GOING ON HERE FOLKS???? YEESH! Catch(22+(1/0)) --- for you TI calc people out there. ) ).
*NOTE* I read someplace that it is a different Kernel, other places just mention a HAL, either way it must be a pain in the ass to support and I can understand Microsoft not wanting to have to support both ways of doing things, after all, this is the twenty first century, IRQ conflicts should not be a problem. I agree that at times how Microsoft Windows tends to, uh, arrange your IRQs is rather bad, but that piss poor sound quality you hear may very well be a SB:Live, which sucks, horribly.
Turn off Plug and Play OS in your BIOS, as is recommended, if installing Windows2k+. Your PCI slots are most likely already setup to separate a few of them by IRQ, use that if Windows will allow you too. If necessary install devices one by one (recommended in any scenario), yes it is a pain, but it is about the only way of having so many friggin devices installed in a computer at once.
Hell I ran out of IRQs WITH IRQ sharing, I have so many devices that do not like to share IRQs at all. (Dual Head Video Card, TV Tuner, Sound Card, SCSI Card, woh, there goes 4 IRQs already!!!
Re:Soyo Dragon (Score:3, Informative)
wrong! win2k has a different HAL with an ACPI kernel to one without! you cant just 'change' modes.
see here [microsoft.com]
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.
More about ACPI (Score:3, Informative)
Maybe this Abit trick will work with Soyo? (Score:3, Informative)
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 [viahardware.com]
Re:More about ACPI (Score:2)
The OS dictating hardware design? (Score:2)
Its kind of funny because WinXP has had problems with stuff like this. On my Biostar motherboard (Sloat A Athlon), WinXP couldn't shut off the computer. It would shut down, except hte fans (all LEDs off, etc) and then the computer would turn back on again! I had to manually power it down. The most recent XP patches finally fixed it. If Microsoft can't figure out how to properly turn th computer off, can they be trusted to use ACPI to put one to sleep :) :) :)
Re:The OS dictating hardware design? (Score:2, Interesting)
What you described happens when you try to do a w2k shutdown on that board.
The other thing is, on NT4, they had an APM thing that properly shut down the thing, but microsoft won't make an equivalent one available for w2k+
Clearly they have the code to make things work, and I wonder why they don't have that available as an option somewhere to use different apm/acpi routines. It's not even like it's going to affect the rest of the system since this is a shutdown command and any instability introduced at that point will quickly be irrelevant.
Something like this and the article makes you wonder more about those theories that microsoft is in league with the hardware manufacturers to continually update your hardware.
Re:The OS dictating hardware design? (Score:4, Insightful)
If the option to disable ACPI was there then you can bet some lazy motherboard manufacturers would ship it in the disabled mode just to avoid the trouble of getting ACPI to work properly.
If you ask me, the solution here is to fix whichever isn't handling ACPI properly, FreeBSD or the motherboard BIOS, not to complain about Microsoft..
Is it possible... (Score:3, Interesting)
The only reason I ask is that it seems like we'd see more reports of other motherboards having trouble.
Isn't that interesting... (Score:2)
So maybe we'll see a truce in the Linux/*BSD feud over this one...
ACPI != problem. ACPI == solution. ;-) (Score:4, Funny)
Enter ACPI. A weighty specification that you can beat a mugger to death with. Big, juicy, complex data structures. States and modes out the wazoo.
All implemented by heroin-addled BIOS writers working in perpetual darkness, in a basement in Taiwan. Mmmmmm....bugs....
ACPI is Ballmer's last hope to return Windows users to the level of crappiness they love and expect.
Don't buy this board. (Score:3, Insightful)
get "WinXP Certified" is not in the best interest of
the consumer by refusing to buy this board, and any other product that does this.
Re:Don't buy this board. (Score:2)
the 10% of their business that they are going to lose just b/c we don't buy their shit isn't going to change their minds.
I refuse to buy MS products. Does it stop Billy from making it? I refuse to buy foreign cars, does it stop Japan from bringing them in?
Come on. It is a personal thing but it isn't going to work.
What is going to have to be done is companies are going to have to understand that being WinXP certified means absolutely nothing, but that will never happen either.
Ahh, the joys of an imperfect world.
Re:Don't buy this board. (Score:3, Insightful)
Re:Don't buy this board. (Score:5, Insightful)
First of all, duh. Of course we should all refuse to buy this board. Except that generally I look at board reviews before I buy a board, and also prices. I very rarely stop by slashdot to check if the makers have offended the slashgods.
Second, how come every other story on slashdot causes every single karma whore to come out of the woodwork calling for a boycott. I am fed up of this. If you are too, then boycott the boycotts. Buy CDs and DVDs. That'll show them.
not_cub
Support Open Hardware (Score:5, Informative)
Boycott proprietary hardware!
Offftopic: Stupid website for Open Hardware (Score:2)
They may have noble aspirations. They also have one of the world's stupidest webmasters. As a prime example of gross stupidity, I refer you to their FAQs [open-hardware.org] page. Five silly questions as links, each of which is is a javascript function that opens a new window containing a small amount of information. Opening the page in a browser without javascript enabled yields a uselesss webpage. Even the javascript is stupid, as the function that opens each of the 5 the windows is actually 5 different functions, identical except for the name of the file they reference. Think web programming, as done by Kelly Bundy.
If this is satire, it's fucking brilliant. Otherwise, god help them.
The board sucks (Score:3, Insightful)
The best board to get right now are the MSI Athlon boards. XP certified, fast as crap, rock solid.
Buying shitty hardware may save you some money up front, but you'll pay through the teeth down the road.
Read carefully, it says ACPI cannot be disabled (Score:5, Informative)
This means that ACPI is always ON, not off.
Re:Read carefully, it says ACPI cannot be disabled (Score:2)
Even if the user knows damn well what they're doing and they're using an OS that supports ACPI on that motherboard. Because, you know, nobody ever runs anything other than Windows.
Re:Read carefully, it says ACPI cannot be disabled (Score:3, Informative)
OnNow and ACPI Requirements
Power management, docking station support, and Plug and Play capabilities for mobiles must be wholly ACPI-based, as APM support has been removed from Windows XP. [A3.4.7]
Desktop system support required for S3 and Fast Boot capabilities, based on Windows XP advances for ACPI-compliant power management. [A1.4.2]
Desktop and server systems must implement ACPI-based APIC support, because of how Windows NT®-based operating systems process interrupts. [A1.4.11]
ACPI-based support for multiprocessor systems, based on Windows XP/Windows Whistler Server support. [A1.4.12]
PCI-based network adapters for desktop systems must support wake from D3 cold, to ensure correct system-wide support for wake from sleep states supported under Windows XP. [B7.1.4.4]
Re:The board sucks (Score:2, Redundant)
Re:The board sucks (Score:2)
Just because it has high speeds and is packed with so many extras does not mean the engineers designed it right. Too often they just stop if it works with Windows, and often Windows is even doing things inconsistent with the hardware specs.
Most motherboards are moving that way. (Score:3, Interesting)
Yes, it's required for XP-- and it was greatly encouraged for 2000 Pro-- ironically, turning ACPI off fixed a lot of problems I was having with my KT7A-RAID board.
New bios revisions of existing boards sometimes disable this, so watch out!
Some more popular motherboards have "hacks" that can add this functionality back.
Try looking for an "unofficial" support forum for Soyo or whatever.
Go here [viahardware.com] for the best KT7 faq which answers all these questions for that board, but provides interesting ACPI info, as well.
A taste of the future (Score:5, Informative)
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
Re:A taste of the future (Score:5, Interesting)
Not to point out obvious stuff, but if producers of Windows compatible motherboards consistently take longer to deliver product and charge more to cover their R&D and production expenses because of incompatibilities like these, it means that Linux-only mobos are gonna come to market faster and cheaper. In other words, it adds one more reason that it's cheaper and more efficient to run Linux instead of 'doze. That's just gonna hurt MS in the long run. DOJ action is entirely unnecessary.
Re:A taste of the future (Score:3, Insightful)
Replace Linux Only with "non-XP certified", and it makes more sense. I think anyone building their own machine is going to be smart enough not to care about certification as long as it works.
Tim
Excuse me? (Score:4, Funny)
Hey now. That's also "Sun Fag", "IBM Fag", "MIPS Fag", "Alpha Fag" and even "Cray Fag" mode. Oh no mister bill, those dang homosexuals have corrupted the entire industry!
Hmm, why don't they let us audit their code?
Isn't it obvious? You can't accessorize.
Hush. (Score:3, Funny)
Re:A taste of the future (Score:2, Interesting)
I always find comments like this interesting. What makes anyone think that the Democrats are any better at protecting "Your Rights Online"? Correct me if I am wrong, but wasn't the DMCA passed under a Democrat president, and mostly supported by Democrats? Also, isn't the SSSCA being touted by a Democrat senator and has mostly Democratic support, while the Repulicans oppose the law? I really try not to be partisan, but to be honest, I think the Republicans are your best bet for protecting your online rights, not so much because of their politics, but because they are in the back pockets of companies that oppose oppresive computer legislation. Sure Microsoft is one of the companies that owns them, but Microsoft, IMHO, is a lot less evil than the MPAA/RIAA crew, and the Democrats seem to be the bitches of the entertainment industry.
Don't buy SOYO (Score:5, Interesting)
It probably started about 2 years ago. SOYO first started saying to suppliers that slight bits of soldering and addign of wires had to be done with their mobos. When this was done, the boards ran just fine.
Over time, there were more and more modifications that had to be made to their new boards for them to run stable. This was a huge pain for suppliers because they kept having to make little physical fixes, taking up both time and manpower. Eventually, many of the boards did not run properly even with heavy modification as instructed by SOYO.
Finally about a year ago, our main supplier of SOYO boards threw in the towel and stopped supplying them. For some mobo models, the RMA rate was over 60%. I annihilated my inbox by accident so I don't have the statistics anymore, but the overall RMA rate for all SOYO boards for our supplier was over 40%. Of course this was not acceptable so the line was dropped.
Thus, SOYO boards are not reliable. Just don't by them in the first place. Save yourself the trouble.
Re:Don't buy SOYO (Score:2)
I've got too many friends in the PC sales and service industries who say to "avoid Soyo like the plague" because of high RMA problems.
I've noticed that often, the boards don't die outright either. They just develop an insidious little bug/problem that's hard to convince a dealer is really caused by a defective board.
(One of my own Soyo boards started randomly freezing up whenever I used a GeForce video card with it. It'd behave with an old PCI NVidia TNT2 card, but not with either a Geforce 256 or a Geforce 2MX AGP that I tried it with. I knew someone else with the exact same board who had a Geforce 2MX working just fine in his, though. Same BIOS revisions on everything, too.)
AGP troubles too (Score:4, Insightful)
Some of our senior engineers have been in contact with their engineers, and they seem to be telling us the problem is ours, though we are following their specs to a tee.
Why can't it be easy like it did in the days where you supported a few int 10h BIOS calls? (sigh) Now that was cutting-edge for 1989!
Re:AGP troubles too (Score:2)
Funny, ppl BEG on how to turn off ACPI. (Score:2, Insightful)
Re:Funny, ppl BEG on how to turn off ACPI. (Score:2)
ACPI is stuck in *ON* mode, it CANNOT be disabled with this BIOS.
The post is not very clear but I think .... (Score:2)
One guy said APM took over from ACPI and that's just the other way around....ACPI is the new standard.
I think cliff answered his own question. (Score:2)
MS wanting a feature disabled that makes a board incompatible with other operating systems? My god, what a coincidence!
Misreading the article (Score:2)
That's a big difference.
Here's how 2000/XP Handles IRQ resources in ACPI (Score:5, Informative)
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 [microsoft.com]...
Re:Here's how 2000/XP Handles IRQ resources in ACP (Score:2, Informative)
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".
Re:Here's how 2000/XP Handles IRQ resources in ACP (Score:2)
Re:Here's how 2000/XP Handles IRQ resources in ACP (Score:2)
12 paragraphs of gobbledy-gook TLAs, obscure commands and oddball subjects makes me glad that somebody [apple.com] doesn't require me to be a hardware engineer just to play Solitaire.
Re:Here's how 2000/XP Handles IRQ resources in ACP (Score:4, Informative)
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.
Enough already, here's how it really works... (Score:4, Informative)
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....
ACPI rocks, but can cause severe instability. (Score:5, Informative)
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. [tweakersasylum.com] 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 [usb.org] 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.
Re:ACPI rocks, but can cause severe instability. (Score:5, Informative)
I experienced the exact same problems you are talking about using a Tyan Trinity 400 motherboard with a Intel Pentium III 850Mhz processor. I fought with this issue for quite some time, and was never able to get any stability out of the machine. I had all of the PCI slots filled with expansion cards, and I believe this made the problem substantially worse.
I ended up replacing that motherboard with an Intel D815EPEA2U board, and have experienced zero problems. In fact this Intel board supports high IRQ settings as some of my cards are reporting being at IRQ 23, etc. Yes, now my computer simply rocks.
I also have an Intel SE440BX board in another computer, which is pretty solid but that one doesn't work with my Adaptec 2940(known issue) so I can't say it rocks.
Again, I think this is a VIA problem. This is one of the reasons why I am reluctant to buy AMD processors, although I have not heard if people experience similar problems with boards built upon the AMD 761 chipset, etc.
Re:ACPI rocks, but can cause severe instability. (Score:5, Informative)
You may also be blaming VIA for AMD's problems.. their earlier AMD chipsets were much more unstable than the kt266a, their current one, and kt333, the upcoming chipset. It used to be a necessity to put their 4in1 chipset drivers on a new OS install ASAP. You still need the drivers for Win2000 and below, but Windows XP has native VIA drivers that are WHQL certified and are very stable.
I'm a happy AMD/VIA user. I have a Shuttle AK31A (KT266A) board with an AthlonXP, running WinXP. I have had my problems with AMD/VIA however.. my first AMD/VIA was an Abit KT7 which had the KT133 chipset. It was much more unstable and it had major issues with some of my older PCI cards.
Why sharing interrupt lines is stupid (Score:5, Informative)
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--
Re:Why sharing interrupt lines is stupid (Score:4, Informative)
Re:ACPI rocks, but can cause severe instability. (Score:2)
If Windows freezes because it can't deal with ACPI properly, it's a software problem with Windows. If Windows freezes because the ACPI implementation doesn't meet the standard it's a hardware bug and the hardware should be fixed.
When it comes down to it, who's problem it is becomes irrelevant - it's a problem and a big one that has plagued x86 systems since it's inception. Please tell me that someone, somewhere can come with a way to fix this! (For the x86 line, Macs and probably a variety of other systems have never had IRQ conflict problems.)
Re:ACPI rocks, but can cause severe instability. (Score:5, Informative)
(Note: I am not an ACPI expert, but I know far more than most posters here, since I was once program manager in charge of Win98 and NT5(W2K) for a large computer company here in Austin. ACPI was a major PITA for me for about a year, and a key hurdle to the Win98 product launch.)
There are several points that need to be made about ACPI, Microsoft, and hardware:
1. ACPI support as been required by Microsoft since Windows 98. Win2K and XP *really* want it. MS wants APM to have died back in 1998, along with the rest of the "legacy" stuff. Yes, Virginia, Microsoft dictates with an iron fist the features of the hardware you buy, right down to the behavior of the power switch. Even (or especially?) the largest OEMs must comply with the MS hardware dictates, or face losing the OS discounts that they *must* have. (When MS says "You Must Comply", they mean it: In general, losing the OEM discount more than consumes the entire margin on a box, putting the OEM immediately out of business!) This is probably the area where MS most flagrantly and illegally leverages its monopoly, but it gets very little attention - even many people in the industry don't realize the extent of MS' power and control over computer hardware and the companies that build it.
2. ACPI is very different in 98 and W2K/XP. For reasons that boggle the mind, the Win98 team built their own terribly broken ACPI implementation rather than using the properly conforming, standards-compliant ACPI code written by the NT group. It's not a stretch to say that the Win98 ACPI code is some of the most profoundly broken code ever released on a large scale. Microsoft knew it was that badly broken, but the decree came down that it *would* ship by the RTM date as an in-your-face message to Janet Reno and the DoJ. (Although I have to laugh at the Microserf that once joked, "Q: What's the best thing about Janet Reno? A: Her looks.")
As a result, even though the ACPI code was known to be broken and non-functional in Win98, it shipped anyway, and the OEMs had only 90 days to begin shipping machines with Win98 (or lose that discount again - the stick, at least, is consistent.) It was essentially left to the OEMs to work around the twisted wreckage of the Win98 ACPI code. This in turn, forced some very bad decisions, because a BIOS that worked with NT (which was correctly engineered) would NOT work with 98, and vice versa. (This is when many just started putting ACPI on/off switches in the BIOS, which was an effective, but terribly ugly way to deal with the problem, given that a major purpose of ACPI was to eliminate user intervention with the BIOS!) In our case, a brilliant and observant BIOS programmer noticed something wierd, and used it to create a truly scary, but effective work-around: He noticed that NT and 98 made the initial ACPI call very slightly differently - in essence, it was possible for the BIOS to tell which OS it was serving. This led to a crash re-write of huge tracts of the BIOS to support a truly bizarre behavior: Instead of writing the ACPI tables at initialization, the BIOS would wait for the first ACPI call to see what OS is running, then re-write the ACPI tables on the fly to either work correctly (NT), or work around grisly broken code (98). This is NOT the sort of thing a BIOs should be doing, and explains why some modern BIOses are so large and complex - they are essentially workarounds for bugs Microsoft has rendered more or less permanent. It also explains why virtually every new MS OS release requires yet another BIOS upgrade, and why the correct BIOS for your machine may be determined by the OS you are running. Obviously, unless the dynamic approach above is used, it can be effectively impossible to have a properly functioning dual-boot machine...
3. Now that MS senses that they are just getting a slap on the wrist from the feds, I'm told they are starting thier strong-arm tactics again. It wouldn't surprise me a bit if
ACPI is a pretty good thing, far better than the kludgey APM, but it got botched by MS' own ineptitude. Linux and BSD implementors need to use NT/2K/XP as their model, not 98. Sadly, we've seen similar faux pas with USB, device bays in laptops, and more recently, Bluetooth.
I think perhaps the most frustrating thing is how MS claims to be driving innovation, when in relaity the are holding the industry back by years.
Re:ACPI rocks, but can cause severe instability. (Score:3, Informative)
You don't explain what exactly the is that you think AMD chips have. Furthermore, your list of steps taken toward system incompatibility ends with:
-- Said person goes and manually messes with IRQ settings, thus wreaking havoc on the poor commputer that functioned perfectly before.
Which is the real cause of the problem you are describing.
I just like to take the time to point out that I use an AMD processor, and that the last Intel-based system I ever owned was a P200MMX. My machines (self-built) are ALWAYS reliable, and do not have problems with ANY version of Windows, including ACPI support.
In fact, I usually find that many stability problems are directly related to the quality and condition of the hardware, such as:
Accidentally put a small scratch on the motherboard? Looks okay, probably didn't cut a trace, right? No, but if it got down to the trace, you just created a point of extra impedance in the trace... future stability problem. In fact, even if there is no obvious damage, if you dropped the end of the screwdriver onto the motherboard, it may have caused subtle damage to the circuitry that can show up as stability problems.
I once saw a system come in that had problems, only to find a loose screw under the motherboard.
Simple way to improve a system's stability (physically, and in software): Put in ALL the screws that belong in the case. ALL of the drive mounting screws. ALL hardware mounting screws. Do NOT put in one here and there just to keep things tied down... put them ALL in. Not only do they help anchor hardware and dissipate vibrations from moving parts, they provide a ground path for shielding, and shielding from electrical noise is important. Thumbscrews are fine, and I recommend them.
Another one: Don't "loop" cables that are too long. Always use cables that are the correct length for the application. "Looped" cables create larger magnetic fields than ones that are not. Magnetic fields can induce spurious voltage potential in nearby circuits.
On that subject, keep the cables as far from the surface of the motherboard as possible, for the same reason. Use good quality cables. Also, I've heard of more problems from rounded IDE cables over flat ones.
Tip on RAM: Always use high-quality, name-brand memory, not no-name junk from god-knows-what-fourth-world-country. Memory that is even the slightest out of spec can cause intermittent problems.
Fans and cooling: Where possible, lways install dust filters where air intake occurs. For intake fans on the back of a computer, there are "snap on" filters that can be mounted exterior to the fan. Clean filters regularly, and blow any dust out of the computer periodically.
When installing fans, and multiple placement options are possible, think of a place that gets greatest airflow. Every other fan should be an exhaust fan, not counting the power supply fan. Try to think about air current in a system.
Make sure there is enough cooling for the hard drives, as they can get very hot. My policy is one additional fan for every two drives installed.
I didn't mean to turn this into a class on system design, but that is how you build a rock-stable system. I've built computer systems for myself and for others since my first '286 way back. I DO have experience here.
Re:ACPI doesn't rock (LONG) (Score:5, Informative)
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.
HOLY SH** - PLEASE MOD THAT UP (Score:2)
Thank you.
Re:HOLY SH** - PLEASE MOD THAT UP (Score:2)
Re:ACPI doesn't rock (LONG) (Score:2)
Does it really matter ACPI option is turned off? (Score:2)
My Cmedia 8738, GeForce 3 Ti 200, Via (Rhine) Ethernet, and three USB controller hubs are all on IRQ7. All the devices work great in both Windows and Linux.
As I somehow doubt the Dragon+ was purchased as a Server board, why not just use Linux which works properly?
You could run FreeBSD in VMWare if you really can't do without it.
Re:Does it really matter ACPI option is turned off (Score:2)
Using ACPI under Windows of course as well. Although after many years of lacking enough IRQ's I'm rather uneasy about IRQ sharing
This does not mean I haven't had issues with ACPI. My laptop (PIII 500 Tecra) had issues with IRQ sharing. There were audible clicks with the sound while the infra red port was polling for other infra red devices. Simply disabling the infra red port cured this issue.
Similiar to W2K - workaround (Score:3, Informative)
Had a similar problem with my Dell Dimension... (Score:2)
Damn windows put freakin EVERYTHING on IRQ 9 per the ACPI capability. Only with the hardware I had, it made it VERY unstable even under 2k's supposed ACPI compatibility.
That's actually what made me switch to linux. Put RedHat on it and didnt have any issues.
Dell finally released a BIOS update that would allow you to disable ACPI, IIRC. But, it was already too late
I've got 5 devices running off of IRQ 9 and the (Score:2, Interesting)
I've got 5 devices running off of IRQ 9 and the thing is rock solid, never had a crash since early 2.4.0pre days and it probably wasn't because of an IRQ problem.
The Linux kernel has ACPI support in its future and it all started back in 1999 [zork.net]
Anyway check this out...
[root@haemal]:/proc# cat interrupts
CPU0
0: 29750549 XT-PIC timer
1: 87289 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 2 XT-PIC serial
5: 183414591 XT-PIC EMU10K1
8: 3 XT-PIC rtc
9: 1551326 XT-PIC acpi, usb-uhci, usb-uhci, eth0, eth1
10: 1318690 XT-PIC ide0
12: 2323801 XT-PIC PS/2 Mouse
14: 89064 XT-PIC ide2
15: 62 XT-PIC ide3
NMI: 0
LOC: 29751193
ERR: 46561
MIS: 0
(Legacy != obsolete) ? (Score:2, Interesting)
I found point 5 particularly interesting:
WL-5. System and components meet reduced legacy support goals
Linux advocates pride themselves on the ability of the system to run on old systems. However, there is an argument for getting rid of obselete technologies. While M$ windoz's requirement for top of the line system's smacks of promotion of consumerism for consumerism's sake, My question is this:
How do we compromise between supporting legacy systems, without slowing the pace of tech development in order to accomodate them?
"Designed for Windows XP" sticker (Score:2, Insightful)
This list of requirements (which, btw, doesn't force ACPI to be disabled) is for companies to market their products as "Designed for Windows XP"
Ok...who are the people buying motherboards and other parts separately so that they can put it all together themselves? "The Geeks"
The companies who I would picture to be most worried about having this sticker are companies who use completely proprietary systems with Windows XP pre-installs anyways (Dell, Gateway, Compaq, etc) and need to market their systems as such. If that's the case... no one can complain about their system not being linux or anything compatible because they bought a "Designed for Windows XP" system. Designed for XP... preinstalled with XP... marketed with XP.
To sum it up... this sticker has a much lower value than one might think...the only people who need it are... the people who need it (make sense?)
-kwishot
Misleading headline / DRM (Score:5, Interesting)
That headline really needs to be changed. It should read something like "ACPI Forced On in WinXP Certified Mobos"
Also, did anyone else notice this little gem on the requirements page?
Does this mean hardware support for DRM in sound cards?
Re:Misleading headline / DRM (Score:5, Interesting)
Audio devices must implement Digital Rights Management
Does this mean hardware support for DRM in sound cards?
This means implementing SAP (SECURE AUDIO PATH). Not only must the hardware contain DRM, but the software must be approved and signed by Microsoft. If the driver is not signed it won't work. Read this Wired article explaining SAP. [wired.com] Wired: "SAP adds 'static' interference to media files that require video and audio cards to authenticate themselves with Windows software before they can be played."
What happens when you take your pefectly good sound card out of your Win98 500mhz system and stick it in your shiny new XP 2000mhz system?
You can't play your windows media player files.
Why? Two reasons.
Number one) It is your sound card that is incompatible. Therefore it is not Microsoft's fault. Blame the sound card manufacturer.
Number two) You are a Pirate. Therefore it is not Microsoft's fault. It is your fault for being a Pirate.
It's just another case of Microsoft leveraging it's operating system monopoly to enforce a new DigitalRightsManagementSystem monopoly. In other words, nothing out of the ordinary. Nothing to see here, please move along...
-
Insane, but not too surprising (Score:2, Interesting)
And second, don't totally blame Dragon for this. Win XP wreaks havoc with motherboards, IRqs, etc. It's almost as bad as the old Dos days, but at least back then, with ISA and Win95, we had more of a fighting chance via trial and error.
Case in point: I have an Epox 8KHA motherboard. Works great with Win2K. I added a second partition and installed XP. Once I installed the drivers for my Geforce2 card (from Windows Update, no less), WHAM! Blue Screen of Death. After hours of flashing my BIOS, and trying other drivers (both WHQL and Nvidia beta), I gave up and went back to 2K. I don't know what the hell MS did, but it sure screwed me up.
Win2K workaround (Score:2)
I have a ECS K7S5A motherboard that I had to disable ACPI in the BIOS, otherwise Win2K would blue screen on setup -- this blue screen even tells you to press F7 at the setup screen "when it prompts press F6 for RAID devices" to *silently* disable ACPI support!
Can anyone enlighten me WTF does every device need to be on the same IRQ ?? What's wrong with having every device on it's own IRQ ??
This isn't new (Score:2)
Read here [viahardware.com]. Personally I don't think you should boycott SOYO, Abit, or any other manufacturer because they wanted to get WHQL..
Now I really, truly, mean no offense to your operating system when I say this. I don't write OS'es, and yes I have no idea how hard it is to write the low level code. But, the PCI spec has been around for close to ten years, and shared IRQ's have always been a (optional) capability for PCI devices. Initial devices had problems with shared IRQ's. But today with no ISA, and card manufacturers learning to play nice, shared IRQ's are a reality. Shouldn't your OS support them by now? I have 2 network cards, SCSI, and sound on the same IRQ right now, and it works fine in Red Hat 7.2 and Windows XP.
Nothing new (Score:2, Informative)
ACPI (Score:2, Interesting)
Regards -- Andy
(Linux ACPI maintainer)
Mandrake Needs this disabled (Score:2)
ACPI is not fully developed. Hardware is slightly head of software, but both don't seem to be totally standardized as far as I have heard (some multiprocesser boards need it, some laptops choke on it in Linux).
So, judging by the artical title, /. is shocked that XP is not ahead of Linux? That's an odd turn of events.
To make it clearer (Score:2)
With ACPI enabled on Dell Laptops in the kernel, they will lock up on switching from battery to wall power or vice versa. Aparently (I could be wrong) at least in Linux you can disable it, reguardless of the BIOS... HOWEVER, if you are unaware of how to compile your own kernel WITHOUT APIC, or pass the option through LILO, your screwed. But, if you could disable it in the BIOS, that wouldn't be an issue.
According to Juan Quintela, the Linux Kernel maintainer for Mandrake Linux "Humm, but the owners of new ASUS boards & similar that have a Promise controller for IDE RAID on board (up machines) will not work without ioapic (the BIOS is also buggy, only that the other way around that the dell laptops). Will try to get noapic kernel option to just work."
Bottom line... Don't assume this is just a Windows XP problem with ACPI, it's just a problem.
Eh? PCI is supposed to be able to share IRQs (Score:2)
I wonder if there's a different problem, such as IRQs being set to `edge' instead of `level' in the BIOS?
And, well, I hate to be an ass, but doesn't Linux handle this just fine?
Please allow me to clear up some garble (Score:3, Interesting)
Anyone want to finish the ACPI driver? It's big and complicated.
Bruce
If I were Microsoft (Score:2)
Before crying "fire" and "panic" which I already see happening, realize that these boards are so flaky they should be avoided at all costs!
And perceptive readers will notice that we are getting the usual single, EXTREMLY biased side of the story. It's the classic slashdot BS. Don't swallow stupid vendor crap hook line and sinker every time folks. Sometimes vendors conviently forget to mention crucial parts of the story. Folks paying attention to the tech area should take claims by one side in a debate with more than a grain of salt. Christ, look at Kazza/Morpheus. You'd think editors would be even more careful.
Anyways, let's get a little more confirmation from the mobo makers such as Tyan/Abit/MSI etc.
ACPI Fix: Flash your BIOS... (Score:2, Informative)
*Flashing the BIOS can be risky for the inexperienced. Don't lose power! (how?) [apcc.com].
It seems like this sucks, but... (Score:2)
ACPI for free UNIXes is under development (Score:2)
FreeBSD 5.0-CURRENT has ACPI, so, unless they back it out, it'll be in 5.0 when it's released.
I think there's already experimental ACPI support in the Linux 2.4 kernel.
I can't speak for NetBSD or OpenBSD, although a search for "ACPI" on the NetBSD Web site suggests that they're at least looking at the FreeBSD effort.
So, even if this were the Evil Plot by Microsoft to destroy free UNIXes that some people have suggested (I see no evidence that it is), it's only going to work for a while.
Bash the board? (Score:2)
This is a far cry from what my previous board, the Asus A7V was doing for me, with hangs in Quake3 about once a day. And my uptimes never exceeded 20 days.
I've been fairly pleased with this board, and my only regret is that it lacks 4 ddr sockets. Oh, and extra Socket A would be nice, but that's another issue entirely.. =)
-fc
ACPI *Should* be required by XP (Score:3, Interesting)
XP with ACPI runs beautifully on my Asus A7V with Athlon chip and even the dreaded Via 4 in 1 chipset.
Look at IRQ 9:
IRQ 0 System timer OK
IRQ 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard OK
IRQ 6 Standard floppy disk controller OK
IRQ 8 System CMOS/real time clock OK
IRQ 9 Microsoft ACPI-Compliant System OK
IRQ 9 NVIDIA RIVA TNT2 Model 64 OK
IRQ 9 VIA Rev 5 or later USB Universal Host Controller OK
IRQ 9 VIA Rev 5 or later USB Universal Host Controller OK
IRQ 9 Intel(R) PRO/100+ Management Adapter OK
IRQ 9 SB PCI(WDM) OK
IRQ 9 Promise Technology Inc. Ultra IDE Controller OK
IRQ 13 Numeric data processor OK
Now ask me how many times XP has crashed since I installed it after purchasing on day one...
(The answer is zero. Not once. The thing is more stable even than my G4 running OSX)
Give 'em a break for once. They may suck as a corporation, but XP is a decent product, and there's nothing at all wrong with them requiring ACPI "always on." It'll save most users the trouble of IRQ conflicts while still letting them plug the latest shit from CompUSA into their PC every month.
Re:Because... (Score:5, Informative)
-
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 [cknow.com] is deprecated, and ACPI [cknow.com] is the new standard.Re:Because... (Score:2, Informative)
Real Issue: MS ACPI vs. ACPI (Score:2)
The implication of this statement is that Windows XP ACPI is not the same as ACPI. This explains a few things, like why every d**n ACPI BIOS out there violates the ACPI specs and must be patched in order to have a prayer of working with Linux. Of course, even when patched most laptops are working poorly at best.
This is clearly a ploy by MSFT to subvert a standard (of which they are a primary sponsor!) to the detriment of competing operating systems. I'm glad that they've stated it so clearly. Forward this to Bill Lockyer.
Re:Hmmm (Score:2)
Actually, the CURRENT (5.0) branch of FreeBSD supports ACPI just fine. They aren't back-porting it to STABLE (4.x) because there have been too many other changes to the kernel that make it a major effort.
FreeBSD (Score:2)
Actually, FreeBSD seems to be moving more towards Win2k-style ACPI support in -CURRENT (although that's more of a gut-feeling[tm] than a hard fact; I'm sure someone else can elaborate)
Aside from flaky hardware (which you can turn off in most cases), this is a Good Thing, although you can be sure you'll be able to turn it off in FreeBSD if the need arrises.
http://www.jp.freebsd.org/acpi/ [freebsd.org] seems to be about the best page I can find on this.
Re: (Score:2)
Re: (Score:3, Interesting)