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.
It appears that within an hour there was a workaround posted on the same forum.
Have you Meta Moderated t
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.
there is more than one motherboard manufacturer. Foxconn is more than welcome to take a FISS approach with regards to their customer base: the market will issue any required adjustments to their attitude.
The higher the technology, the sharper that two-edged sword.
In my workplace we run Windows, OS X, and Linux. I have the expectation of being able to use Linux on any x86 kit we buy. Absent an explanation or attitude change from this vendor, I won't recommend their kit here for Windows use either. That seems somewhat important so I'll repeat it:
I will not buy Foxconn kit for Windows use if Linux compatibility is impaired.
The title of this trick is misleading. It should solve those problems by pretending to be Windows to the BIOS.
How old is this guy?
If I had a serious problem I would be more professional in my way of contacting support. Certainly his way of approaching the Customer Support is looking like some angry teenager.
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 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".
Check on google.... LOTS of troubles with Foxconn for Linux Users... it's not only 1 user... but only 1 of them took the time to decompile the BIOS.
I can't call that English
First, Foxconn's hardware isn't the only with DSDT errors. Every use a Dell? HP? Considering how sloppily lots of this BIOS code is written, it's a miracle anything works at all. These errors only mean that he's stuck using APM in place of ACPI. If the user wanted a decent motherboard, he'd have bought it from ASUS, Gigabyte, MSI, etc. It's not some conspiracy, it's a cheap motherboard vendor using a defective BIOS that doesn't give crap about it's customers. Really, how's that not normal?
They shouldn't be discriminating against different OSes. Foxconn is deliberately providing Linux with a faulty ACPI implementation rather than simply just following the spec. If they followed the spec, then they wouldn't have to worry about supporting Linux since it would be up to Linux to follow ACPI rules.
Although this vendor seems definitely not trying to support Linux with it's BIOS, the hard truth is that it's not so easy even for those who try. For more information, there is currently a thread on the LKML disussing this and how to improve the situation.
In particular, latest kernels claim to be every versions of Windows at the same time, and not Linux! That's not easy to handle for the BIOS writer...
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.
They are free to choose what platforms to support but, in this case they choose to have a broken bios with a table specifically for Linux that was broken. In this case it look as if they worked on getting it to not function properly. It really makes you wonder.
HTTP/1.1 400
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.
Foxconn has no obligation to support
They went out of their way and expended extra effort to prevent Linux from working on their system. This moved beyond "not supporting", to "breaking" hardware that should have functioned without any effort at all on foxconns part, using what was probably considerable effort on their part to detect what kernel was booting, then developing a fake ACPI table to show only when it detected linux.
The interesting part is that a year or so back, there was an article here about how Microsoft floated a letter around manufacturers asking how to make ACPI harder for Linux to implement. Everyone asserted that we were just paranoid and the only reason ACPI was hard for Linux was because "Linux developers suck", but now it seems we know.
Foxconn isn't exactly a no-name MoBo manufacturer. In fact, you'll find a foxconn board in most gateways, dells, compaqs, HPs, and (yechh) eMachines.
This is active sabotage.
They haven't lost a customer, they've gained an enemy. This is an attack. Do not let them get away with it.
Guess what ? the acpi impyementation in OpenBSD says `oh, sure, we're windows'.
Where do you think this is going ?
Most card makers don't give a shit about linux and other OSes, the only acpi implementation that's going to be tested is... windows!
so, say you're windows, and cope with it, that's the only sane way to make things work.
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!
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
> So let me get this straight. Some small motherboard manufacturer has flawed ACPI tables and
> refuses to fix them, therefore they MUST out to sabotage Linux?
Nope. Let's get you straightened out.
The BIOS provides two sets of ACPI tables; one good, working and one which isn't even intended to work. It checks what OS string the kernel hands it when it boots. If Windows, it sends the good tables. If Linux, it sends the deliberately faulty ones.
The more you know!
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Foxconn also accuses him of making "idle treats".
I want an idle treat.
Badass Resumes
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.
I'm sure we could get ISO to fast track a few "adjustments"
My turnips listen for the soft cry of your love
This is nothing new and there is nothing *fishy* going on. As a side, my MSI notebook also has some non-compliant tables which causes FreeBSD's ACPICA (which was written by Intel) to not recognize the battery status light.
The issue is that Microsoft OSes are not ACPI compliant period. They are semi-ACPI compliant and always have been. Most motherboard manufacturers use the Hardware SDK in order to get the WHQL certification. The SDK provides tools to automatically generate ACPI tables (and in fact if he looks at the DSDT he can see how the tables were generated, typically they are stamped by the SDK).
Nothing to see here...move along.....
Sucks for them that they're going to get some bad press about this as it is now on Slashdot's front page.
I don't have a problem with people getting bad press when they advertise functionality they don't actually have. I don't have a problem with them not including chipset drivers for specific OS's, or utilities coded for OS's they don't want to support. But borking your BIOS to throw a monkey wrench into things if Linux is the OS is pretty messed up.
Hope nobody tries to do something silly like boot a Linux Live distro to recover a system where the Windows OS has gone out on one of these things.
"It is a miracle that curiosity survives formal education." -Albert Einstein
I don't blame them for not wanting to support !Windows. I do blame them for writing broken ACPI tables and trusting Microsoft's legendarily forgiving implementation do their work for them. I do blame them for saying they're ACPI compliant when they're blatently not. I do blame them for not even expressing interest in fixing it when it's pointed out to them.
Sure, they're not necessarily evil, but they are displaying incompetence I find unacceptable in a hardware vendor, and I don't think it's in any way bad that they're getting bad press because of it.
Whatever happened to the concept of generic hardware? It usedc to be that when you bought a printer, it would work with everything. They published the escape codes that you used to change fonts, or draw lines, or whatever. Same thing with modems. You used to be able to grab any modem off the shelf and expect it to work with any computer.
Somewhere along the line, hardware started becoming Windows Only. Modems became Winmodems. Printers became Winprinters. I'm guessing the same thing applies to webcams, and scanners, and other hardware. Now we've got a motherboard with a Windows only BIOS. It sickens me.
"I'm not impatient. I just hate waiting." - My Dad
So he bought an off-brand cheapo board, and it sucked? Amazing.
I want to delete my account but Slashdot doesn't allow it.
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.
But if a user takes the time to find the cause of the problem and tell you exactly what it is, and it is a problem that could be fixed with a BIOS update. Is it a good idea to fix the problem and improve the quality of your product, or ignore it and get a reputation for providing poor quality products?
Sure it will still require some resources to fix, but this guy has already done the hard work of debugging and identifying the cause of the problem.
Poorly designed, or incomplete bios implementations are not the exception. They are in fact a fairly common occurrence. The DSDT table being missing, incomplete, or just wrong is so common in fact, that a number of solutions exist.
See here: http://acpi.sourceforge.net/dsdt/index.php
Non sequitur: Your facts are uncoordinated.
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.
This is more a case of *Microsoft* not being ACPI compliant. The different versions of Windows have historically broken ACPI in hilariously random and catastrophic ways. You can decompile any BIOS on the market and find a similar table. If you're willing to rule out malicious sabotage on the part of Foxconn (which would be a pretty ballsy move given that they manufacture Intel's reference motherboards), the fault can probably be traced back to their BIOS vendor - either AMI or Award, if memory serves.
Especially considering how ACPI doesn't really seem to be the greatest standard so far conceived, and on top of that is an Intel-Microsoft cooperative product, I just wouldn't bet my life and limb on its specification being sound.
I find it odd that quick remarks against Foxconn have been modded "troll" and "flamebait", just like interesting and insightful comments that say something bad about Microsoft usually are in other threads. If you work for MS and have mod points and are modding these comments against Foxconn down, two things:
1. It is suggestive that this is another Microsoft trick against Linux. Your downmodding of anti-Foxconn comments just fuels the conspiracy theories
2. When the metamods mark your mods as "unfair" you my not get mod points again. If I'm given one of the "flamebaits" or "trolls" (except the one that says "first post", that one was fairly modded) I will mod the mod as "unfair" and I imagine other metamoderators will do the same.
I'm checking the "no karma bonus" box, please feel free to mod this ot comment down further if you wish.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
Ok, ya, they probably are falsely advertising, and just shoved it off because they got MS WHQL stickers (most companies do the same anymore)...
But you know what? I don't feel too much sympathy - because honestly, you get what you pay for. Any PC builder with half a brain (which it looks like he has plenty of if he knows how to pick apart the bios) is going to know that manufacturers like Foxconn, ECS, Abit, etc are going to be horrible quality (or at best sub-par).
Basically, he probably was being a cheapskate and went with the $30 or 40 dollar Foxconn board, when for $50, a mere $10 more, he could have gotten a fantastic Asus motherboard, or at *least* MSI or Gigabyte...
"So let me get this straight."
Let's see.
"Some small motherboard manufacturer has flawed ACPI tables and refuses to fix them, therefore they MUST out to sabotage Linux? I feel I've missed a step in your logical deduction here."
You missed not just a step but the entire issue.
You have a manufacturer that provides different ACPI BIOS tables for different operative systems. They even have one explicitly tailored for Linux although the manufacturer says it doesn't support Linux. Then the ACPI BIOS table explicitly tailored for Linux is different from the Windows ones in a way that it is not only non-ACPI-compliant (though the vendor insists in certifying it as such) but even breaks in not a clear manner a Linux install.
Couple it with the fact that Microsoft, a convicted monopoly abuser, is the favoured vendor from current state of affairs and already has a proven track record of getting into agreements with OEMs and manufacturers in order to make competitors look like flawed.
It certainly took money from the vendor to reach such a state of matters. Do you really think the most probably cause to be "general profit-driven apathy"?
"Why the poster persists in sticking with such a POS board with obviously wrong BIOS is beyond me."
1) The point being here not that Foxconn produces "obviously wrong BIOS" but that Foxconn might be producing "maliciously wrong BIOS".
2) Do you really think that, in case there is in fact an unpublished agreement between Microsoft and Foxconn to make Linux look like shit the former won't look for similar agreements with other vendors/manufacturers?
3) Do you really think that, in case there is in fact non-published agreements between Microsoft and other vendors/manufacturers to make Linux look like shit, average "Joe user" (or even me, for that matter) will know the real cause to make an informed decision, as free-market theorists require as a must for a sane economic environment, unless somebody takes the time and effort to vawe the hidden facts?
4) Given the exposed arguments, do you still really think this is really "a tempest in a teacup". I do not think this is a tempest in a teacup but a very serious issue.
After having read the Ubuntu forums I was flat out disgusted at how Foxconn responded to the customer. I have never received a response so rude from tech support. They outright told him to stop sending them e-mail because they did not want to address his problem. Nevermind their poor products... how about their customer service? That is pitiful and they fully deserve whatever comes their way.
People who are born in the age of winmodems assume unquestioningly and "intuitively" that hardware can only be made for an OS and supporting OSs is a cost. In reality, infinite OSs' support can be simply achieved by manufacturing in way that's compatible with open standards. If they can't do that, which is quite normal because sometimes the standards are very feature-less, they should at-least put out technical specifications regarding how an OS can interface with the hardware.
The largest prime factor of my UID is 263267.
The short answer is that some hardware/software interaction is going to be different between various OS versions. Common standards for things like ACPI are supposed to help work around it to some extent. If there's a problem, though, rather than spin new hardware for a bug that comes out on some OS's, it might be more cost effective to code a workaround in BIOS.
If you think about it in terms of doing firmware fixes for option cards to correct problems that can't be completely corrected in drivers, in might make a little more sense. Sometimes those problems will only come out on certain architectures.
"It is a miracle that curiosity survives formal education." -Albert Einstein
They are ACPI Compliant for Windows. You know, the operating system they support. They don't support Linux, so it doesn't matter if the ACPI tables are correct or not.
Now, just don't buy their products and everyone is happy.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
> Maybe I just don't get out much, but I've never heard of that manufacturer.
Probably because they don't sell much under their own label: (Wikipedia entry)
He did write a workaround/fix. RTFP (post). That's how he managed to get the system working with the Windows DSDT.
Change is certain; progress is not obligatory.
I've just opened official ACPI specs and Microsoft's WHQL is NOWHERE EVEN MENTIONED, let alone of being needed and sufficient criteria of ACPI compliance.
IOW, product is ACI compliant when it works in accordance with specs. Once there is violation found, they can no longer claim ACPI compliance.
Is there an industry group that can be contacted in an attempt to force them to remove "ACPI Compliant"? If the original analysis is accurate, clearly they are not ACPI compliant.
Furthermore, since they clearly are breaking ACPI compliance when it detects Linux, and they state ACPI compliance, doesn't this mean they are fraudulently advertising? Seems both the State Attorney General and consumer watchdog groups would like to hear about this.
I have a motherboard (ECS) that gives a kernel panic when any Linux distro tries to boot. Since the installer boots Linux, I can't install or test any Linux distro on it. On one hand I feel certain that there is a bug in the motherboard, but on the other hand a kernel panic is like a GPF, and it should not occur even with bad input. At the very least, add a check and give me a warning or error message better than "kernel panic". So IMO, there is also a bug in the Linux kernel.
Given the fact that this problem with the motherboard is not fatal to any other OS I've tried, I consider the bug in the Linux kernel to be worse than the bug in the motherboard. Should developers have to deal with bad input? Not in a perfect world, but this has never been a perfect world.
They went out of their way and expended extra effort to prevent Linux from working on their system.
Hanlon's Razor: Never attribute to malice that which can be adequately explained by stupidity.
I have my doubts that Foxconn would deliberately sabotage a potential customer set--but I have no doubts whatsoever that they could try to implement Linux support, screw it up, then decide they're not going to finish. After all, their Windows support also sucks.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
I have one for you but it's just lying around here doing nothing
"I'm not a procrastinator, I'm temporally challenged"
This is more a case of *Microsoft* not being ACPI compliant.
We really don't know if this applies here. After all, the BIOS is feed wrong information to Linux, on purpose, which is different that what it provides to Win-OSs. For all we know, it may be providing correct capability information to Windows and simply providing bad information to Linux.
Ultimately, one has to wonder about the motives when a market segment is purposely excluded. No company in their right mind wants to exclude a potential sale unless there is money to be made elsewhere from that exclusion. Or perhaps, as you originally stated, they are nowhere near ACPI compliant and realized early on Linux highlights this fact. Even so - why add additional code to further break things if they are already broken without a monetary return elsewhere to justify the extra effort.
If they didn't support Linux, and were not incompetent, they would remove the OS check altogether and just use the "Windows" table for everything. This is probably already what happens for other unsupported OSes that are not Windows or Linux, such as FreeBSD.
IIRC their XPS systems use the Foxconn hardware as well.
Srsly u guys. U guys, srsly.
Yeah, except for the part where the motherboard claims to be ACPI compliant when it really isn't. That's sort of false advertising.
Not really. Foxconn claims to only be certified to run Windows. Thus, their claim of ACPI compliance is consistent with their advertisement.
So, while the Linuxan may be offended by this whole concept, Foxconn didn't do anything wrong. Their bottom line is apparently unaffected by linux buyers.
Bearded Dragon
The link points here.
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.
False advertising is a subset of fraud, that is, false advertinsing is fraud, but not all fraud is false advertising.
Did you or did you not read the actual forum thread? The Linux-specific paths contain repeated invalid ACPI code which passes through the pathologically permissive Windows ACPI implementation, but hangs a the more compliant Linux implementation. Grep for "mutes", if you want to. Tell me, why the fuck would a machine need its serial ports (IO port range from 0x3f8, about the oldest hardware on a PC, present from before the IBM XT) disabled on Linux and not on Windows?
Furthermore, the Windows side of the ACPI code checks repeatedly that it is indeed running on Windows. And not from any information provided by the ACPI interpreter, oh no: they poke the hardware as a sort of a secret handshake. This is clearly written with intent to prevent Linux from impersonating Windows to the ACPI code.
If that is not evidence of malice, then I do not know what is.
ACPI compliance should be a prerequisite for Windows certification.
They can't claim something not doing ACPI is OK because MS says so.
Here in the UK I would take their sorry asses to the trade commission for false advertisement.
IANAL but write like a drunk one.
Yeah, except for the part where the motherboard claims to be ACPI compliant when it really isn't. That's sort of false advertising.
sort of?
last year I purchased a print server where it stated clearly on the box and the advertisement that it supported usb 1.1 and 2.0. Connected it to my usb 2.0 printer and it didn't work. Couldn't print to the darn thing. Connected a 1.1 and printed just fine.
Eventually the manufacturer admitted they had 'some problems' with 2.0 printers and were kind enough to refund my purchase.
Foxconn should have cut their losses and just said 'oops sorry, my bad' and be done with it.
I guess they can't admit they screwed up and were wrong. Pride will do that.
Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
I had an ASUS motherboard (M2N32 Sli Deluxe) that sounds like it had nearly the same problem back in 2006. I had to disable ACPI, APM, smp, and a bunch of other stuff to get Knoppix or any other liveCD to boot, and then it was still giving kernel errors. Five months or so after the board was released, ASUS pushed a BIOS update that just said "Fixed Linux". Sure enough after a quick reflash everything worked like a charm. Maybe Microsoft stopped paying their protection fee to ASUS?
I read the thread on the Ubuntu forums, where the guy's correspondence with Foxconn was posted. What frustrates me time and time again is seeing these often immature, scathing, and/or accusatory emails being sent by self-proclaimed representatives of the Linux and/or open source community.
In particular, "Yeah, well, I allege that you guys thoroughly suck. Learn how to write a BIOS before you go selling hardware with falsified specs." Come on, how does that help the situation at all? Speculating on the motives of Foxconn and/or the BIOS provider is fine for forums like this. But when dealing with the manufacturer, keep it professional, and stick to the issues at hand. In this case, the issue is that the board claims to be ACPI compliant, and it is not. That can be proven and repeatably verified. In fact, Linux compatibility isn't even an issue here. That the BIOS fails to work with Linux is a side-effect (i.e. Linux assumes a working ACPI implementation, and this motherboard does not provide that).
Of course the bigger problem is that while a standard exists (i.e. ACPI), Microsoft can get away with using its weight to effectively subvert it. Like another poster here said, there are lots of motherboards with imperfect DSDTs that cause various degrees of headache with Linux. This Foxconn board appears to be one of the worst, however.
If I were to speculate, I doubt Foxconn or the BIOS provider (AMI) is actively trying to break Linux. I think it's just poor coding and/or lack of concern for adhering to the ACPI spec (which in turn breaks Linux). The big money is in supporting Microsoft Windows, so that's what the vendors will do. Ideally, there would be an official "ACPI certification" offered by ISO or some not-for-profit third party, and both the vendors and Microsoft would have to comply. But the reality is that while there is a standard, it's not closely followed, and instead has degraded into vendors and Microsoft working too close, effectively preempting the specification. In other words, a Microsoft certification does not imply ACPI compliance. It should, but Microsoft doesn't gain anything from enforcing that.
As for poor coding... I've seen plenty of code written by people who either didn't know what they were doing or didn't care. The result is that you get lots of crummy hacks to take care of special cases. Seriously, why would a company go out of their way to not work with Linux? Yes, conspiracy is a possibility. But I think the more likely reason is that the lousy support was either done by someone who didn't care or didn't know enough to do it correctly... and/or it was an after-thought, a total kludge that didn't go through the typical QA process.
Anyway... I give Foxconn credit for at least replying with readable, mostly grammatically correct, non-form letters. Many hardware vendors I've dealt with either reply with worthless form letters, broken, non-sense English, and/or don't reply at all. Given that this person actually had the ear of a presumably "real" person, I have to wonder: if he'd kept his dialogue more professional, left out the name-calling, accusations and allegations, and remained true to the crux of the matter (non-compliant ACPI implementation), perhaps Foxconn would have been more receptive.
The letter mentioned above (PDF)
Put identity in the browser.
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.
Grep for "mutes", if you want to. Tell me, why the fuck would a machine need its serial ports (IO port range from 0x3f8, about the oldest hardware on a PC, present from before the IBM XT) disabled on Linux and not on Windows?
TFA is wrong about this. Re-read TFA. See my post here. Verify by reading the ACPI spec if you wish.
It's 3e8, not 3f8. It's the second parameter to Acquire() which is a timeout. 3e8 = 1000 = 1 second. There's nothing inherently wrong with that statement in an ASL. The fact that it crashes if you don't change it is likely an artifact of some more complex synchronization problem and subtle differences between ACPI implementations.
Furthermore, the Windows side of the ACPI code checks repeatedly that it is indeed running on Windows. And not from any information provided by the ACPI interpreter, oh no: they poke the hardware as a sort of a secret handshake. This is clearly written with intent to prevent Linux from impersonating Windows to the ACPI code.
Evidence?
All I see on the matter is an assertion posted by the original author of the thread. The only code excerpts he provides shows a match against _OS. Hardly a secret handshake. Given that he doesn't seem to understand what Acquire() does (one of the more basic ASL operators), I don't have much confidence in his knowledge of ACPI or his ability to analyze the dump.
He also adds an _OSI("Linux") section in his revised code, which will never be evaluated since Linux lies and doesn't identify itself in _OSI. Might as well just remove the whole section.
Yes, but fortunately MS isn't the only partner in ACPI, and Bill Gates doesn't get the final word on it.
Look at the state of things. Intel, who did a fairly large chunk of the work on ACPI, wrote the reference interpreter. Intel's interpreter is what is used in Linux, FreeBSD, and several other operating systems. Intel periodically releases updates and fixes to make sure that it correctly supports the published ACPI specification.
MS has their own hacked together interpreter that's fairly broken. The only MS-specific ACPI extensions I know of are implemented in separate tables like WHEA, and not in the DSDT.
The bottom line are, BIOS writers are lazy and often the tables they produce don't meet the ACPI specification. If it boots windows, it's good enough and it goes out the door. I'm all for campaigning for standards support, but making unfounded accusations and attacking their support reps isn't the way to do it.
ACPI is such an absurd feature for a computer. It is quite frequently THE source of many problems. And clearly from this case it makes it easy for a manufacturer to abuse. And they are not the first. I found a machine (or rather the sysadmin at my previous job got me a machine) from HP that would not boot up Fedora, Debian, or Ubuntu due to ACPI crap.
A great many of the features ACPI provides would not even be needed if there was no tendency on manufacturers to keep changing things (e.g. making a moving target for developers of any OS). A standardized computer design would need very little configuration information passed to the OS. And what it would need could be passed to the OS by the actual devices themselves which would be at specific locations the OS can always find (a finite set of device addresses with registers in each device that reveals what device it is).
A whole re-design of the PC to clean up the mess is needed. Nothing can be added on top to fix it. It needs a "start over". But this thread is not the place for me to describe what really needs to be done to make a robust computer system that lets any OS work on any makers machine (but of course, Microsoft would not want that).
now we need to go OSS in diesel cars
That would still require effort on their part.
Que?
Whoever wrote the BIOS put out a great deal of effort, as their BIOS apparently goes beyond accepting the identifier given by the OS (At least as of January, Linux identifies as "Microsoft Windows NT" after a brief bout of identifying as "Linux" and breaking a lot of BIOSes that flipped out when they couldn't recognize the OS) to some other nonstandard method that is capable of identifying Linux even if Linux identifies itself to the BIOS as Windows.
That's not lazy. Nor is it incompetent.
If I have been able to see further than others, it is because I bought a pair of binoculars.
For reference, here is Bill Gates' email asking how they can make ACPI incompatible with Linux.
That would explain the problems I had booting Knoppix, and later Ubuntu live, on some HP machines (my dad's desktop, my friend's laptop).
Somewhat embarrassing to say, "Watch this!" and stick in a Linux live CD and have it hang. I never imagined it would be because some MoBo maker specifically detecting for Linux and then sending it down the garbage chute.
I'm unlikely to buy a motherboard by itself, but if I buy a desktop or laptop, what other brand name products are FoxConn's mobo's hiding inside?
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
People always say not to attribute to malice that which can be attributed to ignorance. After reading all of the communication between Ryan and Foxconn, I'd just like to add another popular saying: You can't fix stupid.
His argument that ACPI was "sabotaged" has been debunked again and again, and even if true in the context that he claims it was, it would have no bearing whatsoever in what a motherboard vendor does or doesn't do with it, to the detriment of Linux or otherwise. This problem is a misleading entry in a value table, which when corrected leads to Linux power management working again when hacked. That alone pretty much invalidates his sabotage claim.
Again, even if true, his link would have absolutely nothing to do whatsoever with the topic at hand.
Offtopic would have probably been more appropiate, but troll is OK. Maybe that will stop him from using his incorrect and misleading journal entries to support his arguments. There are even comments on that JE that disprove his so-called theory.
Or maybe it was the links to Roy Schestowitz's annoying attack blog, who is another FUDster and Digg's equivalent to twitter.
Or maybe he's being modded down for organizing shitstorms like these with his sockpuppets.
Either way...
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
In the past few minutes, the UK technical manager for Foxconn has posted on ubuntuforums.
He sounds genuinely sorry, and says that the bios will be fixed next week, and they will look into their testing procedures.
It looks like maybe OP just had the bad luck of getting a support person who didn't know enough to pass him up to another support level.
because foxconn boards are everywhere.
if you buy a pre-built computer from dell or hp etc 9 times out of 10 it's a foxconn board.