MoBo Manufacturer Foxconn Refuses To Support Linux 696
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."
An the solution is.... (Score:5, Insightful)
Return it and buy from a manufacturer... no need to disassemble the BIOS, your time is worth more than that.
Re:An the solution is.... (Score:5, Informative)
Re:An the solution is.... (Score:5, Insightful)
Re:An the solution is.... (Score:5, Insightful)
Re:An the solution is.... (Score:5, Informative)
You can buy computers pre-installed with Linux from Dell and Walmart. Hard to get "bigger" or more mainstream than that. Not very tricky at all, since you don't have to do the actual installing yourself.
Re:An the solution is.... (Score:5, Insightful)
What scenario would Grandma Maybel need to even know about the registry?
Re:An the solution is.... (Score:5, Insightful)
I haven't needed to use the commandline for general use on a modern linux like ubuntu either...
I have used the CLI on it, but mostly for convenience (wget instead of loading a browser to save a file etc)
On the other hand, i have known many windows users who had to get someone else to perform registry hacks for them to fix something that was broken.
Re:An the solution is.... (Score:5, Interesting)
What scenario would Grandma Maybel need to even know about the registry?
That one is easy for me. I used to do technical Support for Norton Antivirus.
Grandma purchased a Dell computer with 128 megs of RAM running Windows XP. She has 10 things running in the tray and the computer is crawling. She knows just enough to know that viruses are bad. Someone at Staples tells her that the $79.00 copy of Norton Antivirus will fix her computer right up.
Well there are 5 things that will pooch a Norton Install. One of them would be having a nasty virus like Klez on your system. Another is a bad hardware. Another is a corrupted windows installer system. The one that gets granny however is lack of system resources. NAV should only be installed on a system with 70% of system resourcess free, may install on a system with 60% free.
So now Granny calls for support. She can't uninstall. She is going to have to do a manual uninstall. So we email her a document with a procedure to run the computer in safe mode. Delete a bunch of files and folders AND then run regedit and pound a bunch of entries out of the registry
Trust me. I took at least 2 or 3 calls like that a day. The only ones better are the 35 year old moms trying to figure out how they got porn popups on their computer. After all the only people to ever use that computer is her and her 15 year old son.
Re:An the solution is.... (Score:5, Interesting)
If Windows had a functional command shell, it would probably get used quite a bit, too -- it's a fast, efficient way of interacting with the computer, and it provides an easy way to tell people exactly what to do (just cut and paste the following commands...).
But Windows' built-in shell is a piece of shit; it's simply painful to use. (PowerShell is better, but it's not part of most Windows installs.)
That everything has to be done through the GUI in Windows isn't a feature, it's a flaw.
Re:An the solution is.... (Score:5, Insightful)
That's an apples to oranges comparison. "Using the command line" and "editting the registry" are unrelated tasks. It's like comparing how often you use the start menu in Windows to how often you use a web browser in Linux.
Re:An the solution is.... (Score:5, Insightful)
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.
I beg to differ, desktop linux users != linux users.
I purchase 40-50 systems a year as a one man show hosting company, 100% of those systems MUST be able to run linux, and run it without issue. Only 4 of my computers run a GUI, and only 1 of those runs windows, and only to play games, and that machine can dual boot to linux as well.
So yes, I do vote with every dollar I spend by purchasing only linux compatible hardware, but I also am realistic and research what I buy before I buy it. Maybe that is why I have a mountain of Gigabyte, Tyan, Adaptec, 3ware and SuperMicro hardware.
Re:An the solution is.... (Score:5, Informative)
When I worked for HP I discovered that most of the motherboards, laptops and such that HP sold were actually made by Foxconn. I wouldn't be completely shocked if HP server motherboards were Foxconn since I don't believe HP makes any of their own.
Re:An the solution is.... (Score:5, Insightful)
Re:An the solution is.... (Score:5, Insightful)
Personally I do not recommend products that do not support Linux/FreeBSD. Because I use those operating systems? That's part of it yes, but mainly because Linux tends to expose crappy products. Look at the board in question here: "Badly written table". I have yet to see a product where they cut corners in ONE place only. Usually if they're sloppy in one respect, there's a whole nest of other problems you're not even aware of. In the windows world manufacturers like to hide behind smoke and mirrors in binary drivers, and people blame windows for instability. Simply put many hardware manufacturers that release drivers/documentation for Linux are not afraid to do so because it's more than likely they're actually releasing quality products or are at least not afraid to admit to errors and will probably be more likely to fix them. Even if you only use Windows that's an important thing to consider.
Re:An the solution is.... (Score:5, Insightful)
Re:An the solution is.... (Score:5, Insightful)
Yes indeed, had they written the ACPI code to conform to the standard there would be no additional work needed to support Linux. If there were any additional work it would be because Linux was failing to conform to the standard and the Linux coders would get on that quickly due to it affecting multiple systems.
It was definitely a decision on the part of Foxconn to only check to see if it would work for Win rather than using the official compiler and fixing all of the bugs.
Ultimately, there ought to be some law requiring that companies that claim to support a particular spec or standard actually fulfill that obligation or at least have a good faith effort to implement it.
I've hacked away at a few implementations and I generally use the program provided by Intel for that purpose, I shouldn't have to fix the implementation because the manufacturer was too lazy to code it correctly in the first place.
Re:An the solution is.... (Score:5, Insightful)
Re:An the solution is.... (Score:5, Insightful)
What bad behaviour?
If you say your shit is ACPI compliant, it better very DAMNED well be. IF not, youre breaking the law and stumping on consumer rights.
This is criminal behaviour. Its like someone peddling snake oil to cure cancer. Its the exact same crime: they tell you its good for X, but its not true.
They lie about their product, they should be taken out and shot in the head.
Fuck them and the horse they rode on.
Re:An the solution is.... (Score:5, Informative)
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.
Re:An the solution is.... (Score:5, Funny)
I wasn't sure either but Wikipedia to the rescue [wikipedia.org]
Re:An the solution is.... (Score:5, Funny)
I've done some research, and it appears to be a form of watercooling, but for a person rather than a CPU. I've never overclocked myself to the point where I felt that I needed it, though.
Re:An the solution is.... (Score:5, Insightful)
"no need to disassemble the BIOS, your time is worth more than that"
Well, thanks to his dissasembling of the BIOS, you all know that you want to avoid Foxconn products in the future like the plague. That surely is worth something.
Re:An the solution is.... (Score:5, Insightful)
Return it and buy from a manufacturer... no need to disassemble the BIOS, your time is worth more than that.
That's not always the case. And while I didn't RTFA, I'm going to make some general arguments against that statement/
First of all this person seems to be very knowledgeable of these low level details. So, its possible he discovered this very quickly. Being able to make a certain determination and going to tech support with enough knowledge to get you escalated past the triage people is worth your time. If he was able to avoid returning this product, it might have saved him some time.
Second is the fun aspect of this. Maybe he enjoys this sort of research. Perhaps for a faulty car or toilet he would not diagnose it himself.
Finally there is the question of what his time is worth. If he's a college student, or consultant that can't find 40 hours of work in a week then it might be worth his time. My time may be worth x based on my salary and what I command in side work. However, I can't always convert x amount of time into x amount of dollars. He might have a surplus of time at the moment.
Re:An the solution is.... (Score:5, Insightful)
"Return it and buy from a manufacturer... no need to disassemble the BIOS, your time is worth more than that."
He was curious, investigated the problem, found the answer, and informed the rest of us.
He learned something useful, then helped others, and probably had fun/satisfaction doing that.
That would fit my definition of time well spent.
Re:An the solution is.... (Score:5, Interesting)
No no no.
Go read what the guy posted. Its an example of a true community member. This attitude is what spawned the Free Software Movement: vendors should not artificially limit what you CAN do with their shit.
This guy has PROVEN that Foxconn TARGETS speciffically Linux and BREAKS IT.
This is anticompetitive and should be a crime.
Simple, really (Score:5, Informative)
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 [slashdot.org] with his sockpuppets [slashdot.org].
Either way...
Workaround (Score:5, Informative)
Re:Workaround (Score:5, Insightful)
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.
Re:Workaround (Score:5, Funny)
I didn't know Zaphod Beeblebrox read slashdot.
Don't Buy Foxconn... (Score:5, Insightful)
Re:Don't Buy Foxconn... (Score:5, Insightful)
Re:Don't Buy Foxconn... (Score:5, Interesting)
Re:Don't Buy Foxconn... (Score:4, Insightful)
Where do we get a list of Foxconn motherboards?
Um, did you try the internet?
Re:Don't Buy Foxconn... (Score:5, Funny)
Where do we get a list of Foxconn motherboards?
Um, did you try the internet?
Um, well, isn't this the internet?
Re:Don't Buy Foxconn... (Score:5, Funny)
Where do we get a list of Foxconn motherboards?
Um, did you try the internet?
Um, well, isn't this the internet?
No, this is Abuse.
Comment removed (Score:5, Insightful)
Re:Don't Buy Foxconn... (Score:5, Insightful)
Re:Don't Buy Foxconn... (Score:5, Insightful)
Sure, caveat emptor. Mark it one star on Newegg. But there are huge problems with that.
Foxconn makes bits for hundreds of rebranders, so it's harder than you think to avoid it. And, whose mobo is in yeah random OEM PC?
Then there is the problem with evangelism. Joe comes to you and says "Vista sucks". You hand him a Hardy Heron disk? Or, do we ask him for a BIOS dump because Linux works with some Windows PCs, but has random reboots with others?
Re:Don't Buy Foxconn... (Score:4, Informative)
foxconn is crap, anyway! way overpriced and way under-tested and under-designed.
last purchase from newegg: 2 mobos, one new one from foxconn and one 'open box' special that was intel.
the intel one (bare board, nothing - not even an i/o shield) worked. its great. the foxconn didn't even post. brand new board and not even a POST.
calling newegg was easy and they didn't even put up a fight at all abou the foxconn. I bet they know that its a shabby product and only some people will actually keep theirs (if they can even install to it).
if this was a tier1 or 2 brand, that would be one thing. foxconn is tier3 and so they don't even 'matter' to us builders anymore. at least not for when the customer doesn't demand to shave every last penny from cost (each time you do that, you are sorry for that kind of cost-cutting).
Re:Don't Buy Foxconn... (Score:5, Informative)
1999 called and wants it's... (Score:5, Insightful)
Re:1999 called and wants it's... (Score:5, Funny)
Foxconn apparently.
Re:1999 called and wants it's... (Score:4, Insightful)
Except that FoxConn appears to *care*, but they care maliciously. They actively rewrote their BIOS code to detect and sabotage Linux.
Well, the GOOD news is that ... (Score:5, Insightful)
Fine. Won't use them for Windows either. (Score:5, Interesting)
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.
Re:Fine. Won't use them for Windows either. (Score:5, Informative)
On another note, I've encountered Foxconn boards in the past... usually broken and being replaced.
Quick Fix (Score:5, Informative)
Re:Quick Fix (Score:4, Informative)
Read the full thread. It has errors in the windows acpi list that crash freebsd and linux as well.
Re:Quick Fix (Score:4, Informative)
Quoted from a link in the above:
Bill Gates on Making ACPI Not Work with Linux (in 1999):
One thing I find myself wondering about is whether we shouldnâ(TM)t try and make the "ACPI" extensions somehow Windows specific.
It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.
Maybe there is no way to avoid this problem but it does bother me.
Maybe we couid define the APIs so that they work well with NT and not the others even if they are open.
Or maybe we could patent something related to this.
Re:Quick Fix (Score:4, Informative)
DSDT is the bytecode, and it has a standard published by Intel...
Intel also publish a compiler for it.
Microsoft also publish a DSDT compiler, which is far more tolerant of errors than Intel's version as well as varying from the standards considerably, and many motherboard makers use this version.
On linux, grep our dmesg for DSDT.. You should see a line like:
ACPI: DSDT CFFB0440, 64DE (r1 P0004 P0004000 0 INTL 20051117)
INTL means Intel, MSFT means microsoft, an Intel one is almost always guaranteed to work properly and can usually be found on higher quality motherboards.
Re:Quick Fix (Score:4, Insightful)
Actually, we should have an online database of motherboards and bios revisions which use a DSDT which complies with the standards, and a hall of shame listing those that don't.
Immature (Score:4, Insightful)
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.
Re:Immature (Score:5, Insightful)
And how mature and professional is a support drone that says 'don't use linux, use windows vista'??
Par for the course. (Score:5, Interesting)
Re:Par for the course. (Score:4, Informative)
You are aware of the fact that the Dell and the HP is most likely manufactured by Foxconn?
Re:Par for the course. (Score:5, Informative)
These errors only mean that he's stuck using APM in place of ACPI.
Good luck using things like oh, multiple cores, without ACPI. A lot of boards I've seen recently don't ship working MPS info, and half the time they don't even have correct routing in $PIR.
It's not easy for the BIOS manufacturers (Score:5, Interesting)
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 [lkml.org] 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...
Re:It's not easy for the BIOS manufacturers (Score:4, Informative)
Why should the BIOS care which OS is installed? That is backwards. The OS should work with whatever is underneath it.
This goes beyond refusing to support (Score:5, Insightful)
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.
The article reposted - minus some code:- (Score:5, Informative)
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 [foxconnchannel.com]
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 [digg.com]
http://www.reddit.com/comments/6tcv8...their_bios_to/ [reddit.com]
(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!
Whatever happened to... (Score:5, Insightful)
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.
Re:Whatever happened to... (Score:4, Informative)
Actually it is in reverse for webcams: initially USB webcams required proprietary vendor drivers but now more and more webcams support UVC - USB video class [berlios.de].
Re:Whatever happened to... (Score:5, Insightful)
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?
This is not an isolated problem... (Score:5, Informative)
See here: http://acpi.sourceforge.net/dsdt/index.php [sourceforge.net]
Get what you pay for (Score:4, Insightful)
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...
Disgusting (Score:4, Insightful)
My wote goes for the guy... (Score:5, Insightful)
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.
Been there, done that (Score:5, Insightful)
Lack of professionalism, IMO (Score:4, Funny)
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.
Re:Homework (Score:5, Insightful)
Yeah, except for the part where the motherboard claims to be ACPI compliant when it really isn't. That's sort of false advertising.
Re:Homework (Score:5, Funny)
Re:Homework (Score:4, Interesting)
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.
Re:Homework (Score:4, Interesting)
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.
Re:Homework (Score:5, Insightful)
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".
Re:Homework (Score:5, Insightful)
Re:Homework (Score:5, Interesting)
Re:Homework (Score:5, Interesting)
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.
Re:Homework (Score:5, Funny)
Foxconn also accuses him of making "idle treats".
I want an idle treat.
Re:Homework (Score:5, Interesting)
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.
Re:So what? (Score:5, Informative)
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.
Re:So what? (Score:5, Informative)
For reference, here is Bill Gates' email [slated.org] asking how they can make ACPI incompatible with Linux.
Re:So what? (Score:5, Insightful)
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.
Re:So what? (Score:5, Insightful)
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!"
Re:So what? (Score:5, Interesting)
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.
Re:So what? (Score:5, Interesting)
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.
Re:ONE user reporting "weird kernel errors" (Score:4, Informative)
Re:So? (Score:5, Informative)
Re:So? (Score:4, Insightful)
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.
Re:Yay tinfoil hats! (Score:5, Informative)
> 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!
Re:Yay tinfoil hats! (Score:5, Insightful)
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.
Re:Yay tinfoil hats! (Score:5, Informative)
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.
Re:Yay tinfoil hats! (Score:4, Interesting)
"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.
Re:Something I'm missing... (Score:5, Informative)
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.
Re:Something I'm missing... (Score:4, Interesting)
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.
Re:off-brand crap: -1, Duh (Score:5, Informative)
Off-brand? They don't sell much under their own branding, but Foxconn [wikipedia.org] is one of the biggest computer components manufacturer in the world. Lots of HP and Dells I've seen have Foxconn boards.
Re:Foxconn? (Score:4, Informative)
> 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 [wikipedia.org])
Comment removed (Score:4, Informative)
Re:I disagree with most of these posts (Score:4, Insightful)
I already said I was certain there was a problem in the motherboard. If you want to argue with me, at least try to make a relevant point AGAINST one of the two points I made. Since you seem to have missed something, my main points were:
1) There's a bug in the motherboard (feel free to argue against this point, NOT FOR IT).
2) The Linux kernel should be more careful with these inputs to avoid a kernel panic when it runs on a bad motherboard. At the least, it should give end users a more useful error message than "kernel panic". At the most, it should disable the module if it's not critical, and continue booting up.
Re:Quit your bitching. (Score:4, Informative)
ACPI is OS independant. You can't be ACPI compliant for windows and not ACPI compliant for linux.
Re:Its a pity that... (Score:4, Informative)
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 [slashdot.org]. Verify by reading the ACPI spec [acpi.info] 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.