ACPI standards used for specificity

Even though the title might seem silly at first, the simple fact that it is there as it is means that there is some explanation behind. So true.


The open standard ACPI was released in December 1996 by a joint collaboration of the main industry vendors. Its purpose was to provide a common interface for describing hardware bits and pieces that might vary from computer to computer. Just like a hardware description language (HDL).

All motherboards today have a bit of ACPI code in their BIOSes that provide the list of sub devices that they have available for use. These sub devices range from internal timers to fan controls or temperature sensors. This happens because all motherboards are different, in a way or another. Even the most common and basic functional components may need to be configured in a slightly different way between different manufacturers. So this ACPI code is rather raw and important for the lowest levels of the operating system. [we could fork this conversation into the subject of "operating systems: hardware or software?" but we shan't. this post has a different purpose, so let's get on with it].

This, of course, is described according to the ACPI open standard independently of which operating system will be executed. When looking at different operating systems, they have varying degrees of ACPI compliance and robustness. Some have good ACPI interpreter implementations and do things well. They may be able to resist ACPI coding errors and still keep working well. Others are dyslexic with regards to reading ACPI right and break. Break because they read wrong or because they can't handle errors.

So ACPI writers decided to start differentiating their code with conditional bits that refer to specific operating systems. Bits like

if (os==os_identifier_string) {
 do this;
} else {
 do something else;
}

OK, so we start to see some specificity on ACPI code regarding different operating systems. But that's fine as it is being done to avoid or to fix existing or potential problems. On the other hand, Microsoft's operating systems have much more attention on this matter due to two reaons:

• Windows OSs are regarded as the world's (only) operating systems. Manufacturers and vendors tend to ignore all other operating systems on end users' hardware;
• Windows has never been any good at handling ACPI code;

Here is where things start to go wrong regarding ACPI...

My first laptop, an Acer Travelmate 4001 WLMi, had a few quirks in its ACPI code that resulted in some issues [I can't remember what exactly]. Because hacking ACPI code is a nightmare, there was an easier way to handle the. You see, fixes for those quirks were already in place, in the ACPI code itself, but in one of those conditional zones for Windows 2000 and XP. Not for other OSs. Fortunately it is possible to tell the Linux Kernel to identify itself as "Microsoft Windows XP" when decoding/interpreting the ACPI table, so I was able to fetch those fixes and get on with things. Remember: no need to hack or change the code because the fixes were already there.
Hacking ACPI code is not a walk in the park. It's not easy to find, not easy to decode, not easy to read and not easy to write.

In effect, ACPI fixes are being coded specifically for Windows. Fixes that are likely to be relevant and safe for all other operating systems, but because of manufacturers' disregard for everything non-windows, "the others" are being left out.

The dirtiest minds might imagine that this is, in fact, a very subtle (and smart) way to undermine support for non-Windows operating systems. All that's necessary is to discreetly influence [i.e. pay] manufacturers to include differentiated code that breaks things on Linux, BSDs, Solaris, etc. Companies could use an open standard to break compatibilities and enforce monopolies. Coward stuff, eh?

Well... it appears to be happening. Exactly that. See the (adapted) quoted text below along with my comments in between. [The full story can be found here: http://ubuntu-virginia.ubuntuforums.org/showthread.php?t=869249]

Ryan:

I've heard a lot of people ask, "Who the hell is Foxconn", if you use a PC, there's a good chance you have one of their boards, even if it's branded as MSI or some other brand, if you use a Nintendo Wii, XBOX 360, or Playstation 3, Foxconn made that motherboard, this isn't some little dodgy hardware maker with no name that we can afford to be quiet about.
------------
I have disassembled my BIOS to have a look around, and while I won't post all the results here, I'll tell you what I did find.

They have several different tables, a group for Windws XP and Vista, a group for 2000, a group for NT, Me, 95, 98, etc. that just errors out, and one for LINUX.

The one for Linux points to a badly written table that does not correspond to the board's ACPI implementation, causing weird kernel errors, strange system freezing, no suspend or hibernate, and other problems, using my modifications below, I've gotten it down to just crashing on the next reboot after having suspended, the horrible thing about disassembling any program is that you have no commenting, so it's hard to tell which does what, but I'll be damned if I'm going to buy a copy of Vista just to get the crashing caused by Foxconn's BIOS to stop, I am not going to be terrorized.

(...)

Linux and FreeBSD do not work with this motherboard due to it's ACPI configuration, using a disassembler program, I have found that it detects Linux specifically and points it to bad DSDT tables, thereby corrupting it's hardware support, changing this and setting the system to override the BIOS ACPI DSDT tables with a customized version that passes the Windows versions to Linux gives Linux ACPI support stated on the box, I am complaining because I feel this violates an anti-trust provision in the Microsoft settlement, I further believe that Microsoft is giving Foxconn incentives to cripple their motherboards if you try to boot to a non-Windows OS.

The correspondence between Ryan (the techie that uncovered this stuff) and Foxconn support (manufacturer of the motherboard in question) follows. It's a bit edited for spacing reasons. This is fun!

Ryan:

ACPI issues, cannot reboot after having used suspend

Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - 70, should be 69 [20070126]

I get these messages in my system log at boot, I also fail to reboot after having used suspend in a session, it hangs and plays a continued beep on the PC speaker.

Foxconn support:

Do you get the same beep codes if you were to remove all RAM out and then turn the system ON again?

Ryan:

No, because then I wouldn't be able to boot into Linux, suspend to RAM, to get the ACPI failure, have syslogd pollute my /var/log/messages file with it, or read about it in my system log.

In particular, the number of quirks that the kernel has to use, and this invalid checksum are what has me nervous.

If you need me to attach the full contents of /var/log/messages, I can do so.

Foxconn support:

This board was never certified for Linux. It is only certified for Vista. See URL below. So please test under Vista. Does this issue also occured under Vista or Winxp?

http://www.foxconnchannel.com/product/Motherboards/certification.aspx

That was a nice start... So the board is only certified for Vista, but by the way, does it work well in XP?? Just by accident, you know... Because it should, I/they reckon.

Ryan:

The ACPI specs are there for a reason, and broken BIOS's like what is in this motherboard are the reason standard ACPI does not work, I've taken the liberty of filing the report in kernel.org, Red Hat, and Canonical's Ubuntu bug tracking systems, and posting the contents of my kernel error log on my blog, which is in the first several results if you Google search "Foxconn G33M" or "Foxconn G33M-s", "Foxconn Linux", etc, as well as prominently in other search formats, so hopefully this will save other people from a bad purchase, and hopefully kernel.org can work around your broken BIOS in 2.6.26, as I understand that kernel is more forgiving of poorly written BIOSes built for Windows.

I've already gotten several dozen hits on those pages, so you guys are only hurting yourselves in the long run, by using bad BIOS ROMs, as people like me are quite vocal when dealing with a bad product.

Spot on: The ACPI specs are there for a reason.

Foxconn support:

Making idle treats is not going to solve anything.

As already stated this model has not been certified under Linux nor supported.

As you are unhappy with the product- using a non-support operating system nor certified, please contact your reseller for a refund.

Ryan:

I've been debugging your AMI BIOS, and the ACPI support on it is far from within compliance with the standards, I've dumped out the debugging data into Canonical's Launchpad bug tracking system so that we may be able to support some sort of a workaround for the bad ACPI tables in your BIOS, I would hope that you will be part of the solution instead of the problem, alienating customers and telling them to go buy a copy of Windows Vista is not service, your product claims to be ACPI compliant and is not, therefore you are falsely advertising it with features it isn't capable of.

I would ask that you issue an update that doesn't make it dependent upon Windows Hardware Error Architecture, but that decision is up to you.

Please find all relevant data here:

Bug #251338 in Ubuntu: “Bad ACPI support on Foxconn G33M/G33M-S motherboards with AMI BIOS”
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/251338

I appreciate your consideration in this matter.

Foxconn support:

You are incorrect in that the motherboard is not ACPI complaint. If it were not, then it would not have received Microsoft Certification for WHQL.

Refer to: http://winqual.microsoft.com/HCL/ProductDetails.aspx?m=v&g=s&cid=105&sv=&f=&pn=G33M-S&oid=3179

As already stated, this model has not been certified under Linux nor supported.

It has been marketed as a Microsoft Certified Motherboard for their operating systems.

Of course threats don't solve anything. But saying that "this product is ACPI compliant because otherwise MS wouldn't have granted us the WHQL stamp" doesn't either. And they don't seem very willing to try anything else... So I guess the threat was still the only thing that caught Foxconn's support attention... even though it was promptly dismissed.

Ryan:

I've found separate DSDT tables that the BIOS hands to Linux specifically, changing it to point to the DSDT tables Vista gets fixes all Linux issues with this board.

So while I accept that you've gotten some kind of Microsoft Certification (doesn't surprise me), that does not make your board ACPI capable, just that Windows is better at coping with glitches custom tailored to it, for this purpose.

Foxconn support:

Stop sending us these!!!

Yes, go away!

Ryan:

Your BIOS is actually pretty shoddy, I've taken the liberty of posting everything that's wrong with the DSDT lookup tables and how to fix some of it so the community that has already purchased your filth can make do with it, also, it's now pretty much impossible to google Foxconn and Linux in the same sentence without getting hit by the truth, that your boards aren't good enough to handle it.

Foxconn support:

Surely this is the way to ask for us to attempt to fix something that is not supported in the first place.

Ryan:

Would it be so difficult? I mean really? I suppose you've never heard of building a happy customer base vs. just angering everyone that deals with your products to the point they make sure others don't make the mistake of buying them.

You know, I have several computers, and they all support any OS I want to put there, as well they should, if you can't fix the damaged BIOS you put there intentionally, can you at least put a big thing on the site that says no LInux support so people won't make the mistake of buying your stuff?

Your DSDT table looks like it was written by a first year computer science student, it is scary, I will not just shut up and go away until I feel like I've been done right, this can end up on Digg, Slashdot, filed with the FTC that you are passing bad ACPI data on to Linux specifically.

I saw you targeting Linux with an intentionally broken ACPI table, you also have one for NT and ME, a separate one for newer NT variants like 2000, XP, Vista, and 2003/2008 Server, I'm sure that if you actually wrote to Intel ACPI specs instead of whatever quirks you can get away with for 8 versions of Windows and then go to the trouble of giving a botched table to Linux (How much *is* Microsoft paying you?) it would end up working a lot better, but I have this idea you don't want it to.

While I don't agree with the way that Ryan addressed Foxconn support in all occations, he does have a rock-solid point. He has the right to be pissed and they were replying as (not very good) corporate robots, so deserve some angry kicks. If their policy was in fact "not supported - won't fix" than they would not react in such increasingly defensive way.

He was lucky to get enough attention to actually get them to act and try to fix things. No promises of official BIOS updates and no reports of working fixes, but they did do something. Of course they did/do/will deny any explicit attempt to break things on the Linux side. But I don't believe them. It's just too obvious to be accidental.

It takes someone with skills and will to figure these things out. A very small minority of all computer users. And that's exactly why this is actually a good subversive way to subtly improve Microsoft's monopoly. Indeed with the help of the ACPI open standard, corporations are breaking compatibility by introducing specificity in the code.

Sorry for the long rant, but this kind of stuff ticks me off! People that know me know it's true.

Thanks for reading,
PJ.