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."
Return it and buy from a manufacturer... no need to disassemble the BIOS, your time is worth more than that.
If you're planning on running a Linux OS on your machine, don't use Foxconn. If they don't want customers, that's their business.
...Windows hardware back. Seriously, who is stupid enough today not to support linux?
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Yeah, except for the part where the motherboard claims to be ACPI compliant when it really isn't. That's sort of false advertising.
The problem is that Foxconn says its ACPI compliant but its not. It also looks as if they botched Linux by pure purpouse. Why on earth would they have a Linux section in the bios when they dont support it? Something is very smelly here thats for sure. I will keep miles away from Foxconn at my departments no matter if my systems are intended for Windows or Linux.
HTTP/1.1 400
If you follow the link in the story, you would see that the poster claims the following:
1) Foxconn advertises its motherboard as ACPI compliant thus potentially misleading people into thinking that linux should be able to handle the board. The company does nothing to counter such possible misunderstandings. One could argue that Foxconn is not obliged to do anything of that sort but for customers it is not as simple as "doing homework" as you suggest. Foxconn doesn't say that things break on linux. They only say "works with windows" and "ACPI compliant". The only way to check is to buy and use (at least until this story).
2) The BIOS actively looks for the OS and passes a modified table to linux. It does not even ask the OS to identify itself and go along with that identification. It rather keeps on having random checks to ensure it is running on windows. I can't think of any good reason why they need to do that unless they want to actively break things for linux.
3) The poster smells something fishy in Foxconn's behavior. Right or wrong, I don't know. But if the poster is right in his suspicion (which s/he must believe), it would be a natural, rational and justified behavior to bitch and moan about it rather than just return the board for a refund. Society owes a lot to such "troublemakers".
No, actually.
File this under having done the world a service by publishing their findings.
Now we know that at least some Foxconn motherboards do not work with Linux, and Foxconn is not interested in doing anything about that. That's useful information.
From other posts, I gather that the motherboard actually has a table specifically targeted at Linux, which supplies broken settings. So it's more than Foxconn simply not supporting Linux; they've actually gone and broken things.
Finally, it seems there is already a workaround available. I guess Linux is willing to support Foxconn, even if Foxconn doesn't want it to. And, really, this is a case of "yay, open source!"
Please correct me if I got my facts wrong.
Have to agree with you here. This is a case of false advertising if it isn't acpi compliant (there is no 90% compliant, or compliant if you use this-or-that software, all that is just non-compliant). I don't know about the slashdot readers that answer with "so what, just return it", but when I am looking for new hardware, I am very happy if people like him figure out who is trying to screw me with false claims, so I can skip these manufacturers from my list.
molmod.com - computing tips from a molecular modeling
If Windows, it sends the good tables. If Linux, it sends the deliberately faulty ones.
It's still more likely incompetence than conspiracy. Most motherboard manufacturers don't write their own BIOS - they buy a stock one from AMI/Award and make a few changes for their particular board.
What they most likely did was update the DSDT tables handed out to Windows to reflect their hardware, but didn't bother changing the others. So for Linux (and perhaps Win9x) it just has the generic tables that came with the BIOS, which of course don't work for their particular board.
Of course, a BIOS even having per-OS tables is indicative of poor design, since being OS-independent is kinda the whole point of ACPI. That's more of an issue with whoever wrote the BIOS in the first place, though.
While they're probably not out to actively sabotage Linux, it's still poor customer service to refuse to fix it and claim that everything is working fine. Sadly, getting most board manufacturers to fix their broken DSDT tables (and there are a lot out there) is akin to pulling teeth.
It appears that within an hour there was a workaround posted on the same forum.
Okay, so ten out of ten for Linux and Open Source, but minus several million for needing to tweak perfectly good code to compensate for deliberate sabotage by a BIOS.
"I'm not impatient. I just hate waiting." - My Dad
And how mature and professional is a support drone that says 'don't use linux, use windows vista'??
how long until
I don't work for FoxConn, but I do work for a hardware and software vendor. And here's some insight - as I have been in a situation similar to FoxConn - but being both the accuser and the guilty party at the same time ;)
WHQL is kind of a big deal for hardware vendors. The main attractive is being able to add the "certified compatible with Windows" to your product box. Honestly speaking - having the logo there gives you *some* cred with users - at least, with Windows users ;)
So your competitors are nibbling at you, the product has to ship, and you need to have the logo in the box. What do you do? If you're already late to market, you hack. You install all the different flavors of Windows, check if it works - if it doesn't and crashes, well, some of that can be attributed to Windows itself. As long as you can install the OS and pass the certification, you're good, the product ships, you get your bonus and a pat in the back for delivering on time.
So say that during testing you DO install Linux and crashes - time for a reality check. If the product spec said "Windows WHQL is a must", and making Linux happy means not passing WHQL - tough luck. Linux won't run.
Or if "fixing the product so it passes WHQL" means "screwing Linux users", well, let me think about that ;)
Many engineers working on any given product would like to ship the best possible product - the one that has a 100% compliant ACPI, APM, TPM, you-name-it implementation.
But when time is short and the management chain is breathing down your neck . . . you do whatever it has to be done to be able to ship. And hope that once the product is out there, you WILL be able to go back and clean up the mess - and ship a BIOS upgrade. Everyone is happy.
Sadly, by the time the product shipped, you've been reassigned to other product - and you will only go back to the first one if the Windows crowd complains.
The solution is easy - Linux users to boycott the brand. But then again: if the mobo was designed to be sold to another company to be used as the basis for a product that will only run Windows . . . It isn't like you care a lot about losing the Linux business. This is only the reality - hard as it might seem.
And to the guy that originally found the bug: next time, remember that maybe the guy at the other side of the email exchange also thinks the situation sucks, but he's powerless to change it.
Because if even if he was provided with a full working patch for the BIOS (that doesn't break Windows compatibility), he might need to reapply for WHQL if he patches the BIOS - which means more $$$ and time spent on a product that is already shipping. So.
It has not always been a myth. Sure, there may be no such thing as perfectly interchangeable hardware, but most hardware used to adhere to well-known standard interfaces.
Modems all supported RS-232 serial ports, and nearly all used the AT command set. Internal modems had no physical RS-232 port, but to rest of the computer, they looked like a serial port and still presented the same AT command interface. There were no "drivers" to speak of.
Sure, some modems added extensions / features, but as long as you stuck to the core AT commands (e.g. ATH, ATD, ATA, etc), the modem would work the same predictable way regardless of who made it or whether it was internal/external. You were free to choose your terminal software... hardware... operating system... even serial port hardware... the list goes on.
What was really nice about generic hardware was that it worked in a well-known, predictable way. If you were so inclined, you could write your own terminal software, operating system... even create your own hardware if you wanted. The information you needed to get everything working--UART documentation, AT command set, BIOS calls, X86 instruction set, etc... was widely available. The only limits in your way were the limits of your own ability to figure everything out.
You mention the C64 and its own proprietary modems. In fact, the user port on the C64 was RS-232 compatible, the main difference being voltage levels. Many companies designed RS-232 interface kits for the C64 allowing you to connect any standard modem you wanted. The specs for the user port were published in the Commodore 64 programmer's reference manual. If you were so inclined, you could actually build your own RS-232 interface from parts available at the electronics store.
With Windows-specific hardware, we no longer have that freedom. We've lost something -- Now, even if we want to write our own software stack or implement our own hardware, we're stuck -- the information needed to make the hardware work is hidden, locked away in a binary driver that only works on one platform. The only way to make it work elsewhere (e.g. Linux) is to reverse engineer the product -- much more difficult that working against an open spec.
Why do I have to reverse engineer my own hardware if it supposedly adheres to a published / well known specification?