Slashdot Mirror
MoBo Manufacturer Foxconn Refuses To Support Linux
Noodlenose notes a thread up on the Ubuntu forums, where a user is questioning the practices of hardware manufacturer Foxconn. The user describes how his new Foxconn motherboard caused his Linux install to freeze and fire off weird kernel errors. He disassembles the BIOS and concludes that a faulty DSDT table is responsible for the errors. Even though the user makes Foxconn aware of the problem, they refuse to correct it, as 'it doesn't support Linux' and is only 'Microsoft certified.' The user speculates darkly on Foxconn's motives. Read the forum, read the code, and come to your own conclusions. "I disassembled my BIOS to have a look around, and while I won't post the results here, I'll tell you what I did find. They have several different tables, a group for Windows 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.' The worst part is Foxconn's insistence that the product is ACPI compliant because their tables passed to Windows work, and that Microsoft gave the the magic WHQL certification."
It appears that within an hour there was a workaround posted on the same forum.
Have you Meta Moderated t
Exactly. Vote for Linux support with your money. The problem is, there aren't nearly enough Linux users to make a dent they will notice. If it makes you feel any better, I bought a (crappy) Foxconn board once and won't be buying one again.
As our way of thanking you for your positive contributions to Slashdot, you are eligible to disable Slashdot 2.0.
The trouble here isn't that it doesn't support Linux, it's that the motherboard appears to be actively sabotaging Linux. That's a really weird thing to do and deserves investigation.
The point is that they advertised that they are ACPI compatible when they are not. And no, "it works on Windows" is not enough to claim ACPI compatibility.
Here is most of the original article.
The pesky junk filter meant I had to snip some of the code out - sorry.
Posting AC for the usual reason(s).
Foxconn deliberately sabotaging their BIOS to destroy Linux ACPI
Edit: Please tell Foxconn what you think of their behavior:
http://www.foxconnchannel.com/support/online.aspx
You need to put in an email, and then it will bring up a form, choose Complain/Suggest.
Edit: Welcome Digg, Reddit, and Slashdot.
http://digg.com/linux_unix/Foxconn_d..._destroy_Linux
http://www.reddit.com/comments/6tcv8...their_bios_to/
(Will add Slashdot when I know the final URL)
------------
I disassembled my BIOS to have a look around, and while I won't post 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.
-----
How to fix:
Get Intel's BIOS ACPI source compiler:
sudo apt-get install iasl
Dump your DSDT table:
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
Disassemble it:
iasl -d dsdt.dat
Open it in Gedit:
gedit dsdt.dsl
Fix Foxconn sabotage:
Find, the section that starts out with
Code:
If (_OSI ("Windows 2000"))
{
Store (0x04, OSVR)
}
Go down til you get to the first
Code:
}
Else
{
Past that you should see Linux alongside Windows NT, which is above another Else that leads to Windows Me.
Should look like:
Code:
If (MCTH (_OS, "Linux"))
{
Store (0x3, OSVR)
}
Change it to:
Code:
If (_OSI ("Linux"))
{
Store (Zero, OSVR)
}
Copy the section, and remove it and the other characters (CAREFULLY PRESERVING SYNTAX!!!!)
Then move the Linux section to right underneath Windows 2006 section.
_Code removed to get past junk filter_
So there you have it!
Because the OS's have bugs in their ACPI implementations. So the BIOS provides a special version of function with a workaround for the bug in case it detects the specific OS version.
Let's note this is valid only for proprietary OS's (aka Windows). For F/OSS kernels, the BIOS writer can simply report a bug on non-ACPI compliance, and it's fixed soon after directly in the kernel.
no need to disassemble the BIOS, your time is worth more than that.
No self-respecting hacker considers reverse engineering BIOSes a waste of time. Try more along the lines of socialising, bathing, that sort of thing.
This is important and I want to expound on it. I work in a Microsoft shop. Really, it's IIS this, MSSQL that, .NET for all dev, and we've all got the latest and greatest Office suite. Strangely, we've heard rumors that our software is going to be tested Vista, but QA hasn't received a Vista machine, yet. With all of that out of the way, I use Linux in various ways on many of our test computers. Mostly, it is just boot CDs, such as Partimage Is Not Ghost and Ultimate Boot CD. So, just because hardware is meant for Windows doesn't mean that it will never see another OS. Hardware interoperability on the software level is necessary.
On another note, I've encountered Foxconn boards in the past... usually broken and being replaced.
I'm a computer repair technician - if you're in this business you know that Foxconn is a low-cost sub-quality motherboard manufacturer, and their product is unreliable at best. Regardless of what operating system you prefer to use, don't buy Foxconn, unless you like throwing your hard earned money away on something that will probably fail in roughly two years. Now that I said that I'm sure there is going to be someone who thinks that Foxconn is great because they've never had a problem with their one Foxconn product. That's great if you've had success - but I've seen more systems fail with their products than other brands.
Off-brand? They don't sell much under their own branding, but Foxconn is one of the biggest computer components manufacturer in the world. Lots of HP and Dells I've seen have Foxconn boards.
No, it allegedly has a bunch of checks for Linux strewn about in random places which then give bad data upon detecting Linux.
The only person claiming that is the original poster in that thread, whose correspondence with Foxconn and the (!) FTC is instantly accusatory and full of assumption. It's almost as if he started with the premise that Foxconn was actively breaking Linux to be anticompetitive and looked for evidence to support it.
I'd have to see a full DSDT dump to be sure, but from the excerpts posted it looks like "active checking" is just matching against _OS instead of using _OSI, which is a mistake a naive BIOS writer unfamiliar with the spec could easily make. It doesn't help the issue that Linux lies about its identity in _OSI.
The "redundant checks" seem to be present for the Windows code path too, and look more to me like bad spaghetti code copied and pasted multiple places.
I also take issue with
Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead. ;)
It's obviously not trying to crash the kernel, that's not how Acquire() works. The second parameter is a timeout, not a memory address. 3E8 hex = 1000 decimal. The BIOS writer was trying to acquire a mutex with a 1 second timeout.
Changing it to 0xFFFF makes it wait forever, which could potentially cause worse problems as execution will get stuck if the mutex is already held. Multithreaded synchronization is a very tricky problem, and I'm not surprised to see they got it wrong. Without examining the code it's impossible to say what effect TheAlmightyCthulu's changes have, if they're correct or if they merely mask the problem.
Saying they're trying to deliberately crash the kernel is a bit ridiculous.
But then again I'm a BSD guy, so I don't start out with a chip on my shoulder and assume everyone's out to get me. Have seen a ton of shoddy BIOSes in my time though.
For reference, here is Bill Gates' email asking how they can make ACPI incompatible with Linux.