Some people, including myself, have been curious about this, this post will not prove they are, but provide some circumstantial evidence that is mildly damning:
What happened with the AMI BIOS on Intel chipsets?
Many ACPI problems, that did not manifest themselves on Windows, but did/do on Linux and FreeBSD, the most interesting and obvious one of the half dozen or so “bugs” involves how Windows and Linux deal with waking from Suspend, notably Linux will immediately crash on the next reboot.
According to my understanding of Matthew Garrett, this is caused by some incorrect data left on the WAK_STS register, that Vista obviously knows how to deal with, but Linux doesn’t, it only took him a 3 line patch which will be in 2.6.26 branch eventually, and backported or included in the distribution kernels eventually.
So I decided to test Windows XP for this behavior, starting with Windows XP RTM, shipped in 2001, where I found the same hanging issue as on Linux, I tried Windows XP SP1 from September 2002, and got the same problem.
When I tried Windows XP Service Pack 2, dated August 2004, it rebooted correctly.
The funny thing about this is there was no reason for Windows to be patched for this back then because the first “affected” BIOS shipped on *some* Intel P965 chipsets around June 2006.
So why did Windows need to know how to correct the “error” two years before any affected motherboards were shipped?
If this was just a bug that slipped in unintentionally, why did Microsoft patch Windows for it 22 months in advance?
It’s obvious to me what happened…in my theory:
1999/2000: Bill Gates states his intention to give Linux ACPI problems by introducing “features” only Windows could handle, this is leaked into the public domain during an antitrust proceeding.
2004: Microsoft decides that they can get away with this, but they need some third parties to take the fall and call it a bug if necessary, in light of the antitrust proceedings.
They have their software engineers look for something that Linux would be vulnerable to, yet simple enough to play off as a “bug” if the jig is up.
The idea for the bad data on WAK_STS register is formed, Microsoft preemptively patches Windows XP SP2 against this attack.
2005: Microsoft pays AMI to slip this into the BIOS that will be used in upcoming Intel chipsets.
2006: First affected chipset ships, the P965, just a few months before XP Service Pack 1 (still affected by the glitch) is end of lifed, and after the bulk of their users are already on SP2, and also coinciding with the launch of Vista, on which they want to push aggressively on laptops and other mobile devices. (Convenient timing)
2008: There are now several million motherboards that have this issue, many of them are in laptops/mobile devices which obviously need to have suspend and resume or else the battery’s limited capacity will be diminished rapidly, users see it as a Linux bug, decide to go back to Windows (on their mobile devices at least) because it Just Works(R).
I stumbled onto the issue, and decided not only to make the problem public, but very public, mistakenly assuming it to be a Foxconn motherboard issue only, and riled up by a bad encounter with a tech support agent.
Foxconn goes to AMI and has them fix the bug, other vendors (MSI and ASUS) don’t care because it’s just going to cost them money to upgrade, and in doing this they tell all their Linux users that they think nothing of them.
Matthew Garrett releases a patch that lets the Linux kernel work around the bug in all affected boards, a simple patch to fix a “simple” and carefully planted “bug” that AMI introduced into their BIOS, this way all affected users can use Linux and disregard the Microsoft/AMI “bug”.
In any event, it’s over now, Microsoft is definitely on to the next thing, they probably assumed this would fall apart on them eventually, but they also probably have Vista patched against a lot of other “bugs” that don’t exist yet.
Thanks to Matthew Garrett and Foxconn for putting an end to whatever was happening here.
And who doesn’t love a ghost story?
