Foxconn Releases Test BIOS Fixing Linux Crashes
Ryan1984 writes "Only a week after the bad press coverage regarding the Linux-related bugs in a number of motherboards released by Foxconn (which turned out to be the AMI BIOS that several board makers use), Foxconn is the first vendor out with a publicly released test patch that fixes the bulk of the problems, allowing kernel 2.6.26 to run well on the afflicted boards. The remaining issues appear to either be kernel bugs in builds earlier than 2.6.26, issues with the Intel chipset itself, or minor annoyances that Foxconn is still working to resolve. Foxconn representative Heart Zhang has posted on the Ubuntu forums (where the situation began), apologizing for the issues, thanking Foxconn customers and the community at-large for their feedback, and promising that Foxconn will take Linux support and testing seriously, going forward."
I'll consider their stuff. What I can't accept is non-acknowledgment, ostrich-style. That just loses me.
You can't be ahead of the curve, if you're stuck in a loop.
Will it run Linux?
Seriously, kudos to them for taking ownership and addressing this so quickly. I've seen some vendors ignore hardware issues if they hear the world Linux.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Wait, Slashdot told me that Foxconn was in the hole for Microsoft, purposely sabotaging Linux so Windows can live on! But now they're releasing a fix? That's not sabotage!
Help me out here, Slashdot!
Though I will admit I was just as much in on it as anyone else. Perhaps instead of malice or stupidity, it was simply "taking care of the biggest customer pool first."
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
linux doesn;t have kernel bugs. It's open source.
"Hey Michael Dell, when are you gonna fix all the disabled HPETs in your laptops? Hell, when I checked for syntax errors in the DSDT code I found 26 of them! And it's only set up to work with different Windows models, nothing else!!! This is unacceptable! ... Hey.... Hey come back here - don't walk away when I'm talking to you!!!!"
Sadly, this is the truth, and if I could make one wish, it would be that computer makers not make their BIOS code such a damn secret. Dell uses a Phoenix BIOS with an unknown compression set up, and they seem to be extremely secretive about it. (Anyone here of the "delldeco" app? That's gone now, because Dell said so.) I'm also glad that EFI is starting to be used in some motherboard manufacturers.
This is very clever sabotage. Now Foxconn is trying to convince Linux users that we should rush out and buy from them.
Once we build all our rigs with Foxconn motherboards, they trigger the new dormant BIOS bug that destroys all Linux systems.
The only way to repair the BIOS at that point will be a patch that can only be installed from Microsoft BOB, and will come shipped in a shrink-wrapped CD case that can only be opened by throwing a chair at it.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Shouldn't be a mystery why so many xbox's are failing when its this company supplying the motherboards. Fuck em.
I'm going with "shit, we're getting bad publicity! Fix that now!" ... with a little luck, it will be followed with ... "and don't let it happen again!"
This whole soap opera, which probably had more to do with copy and paste laziness than conspiracy theories, blew up out of proportions and gave Foxconn a lot of reasons to believe that Linux users are crazy zealots. Yes, I know that the users who actually harassed Foxconn with "OMG microsoft payed you!!!" emails are just a small part of the Linux userbase, but I'd kinda understand if Foxconn took Linux less seriously after that.
The fact that they're now going as far as writing about the patch in the Ubuntu Forums shows that they consider the Linux userbase large and important enough to be worried about the bad press, even though most of the "bad press" was grossly exaggerated. Not-so-many years ago, a company could dismiss the complaints as "nonsense zealotry" with no worries and no financial negative impact whatsoever. Foxcoon seems to believe that this is not the case now.
So, from a "relevance of Linux nowadays" point of view, I consider this to be a very good sign.
I've said this before about ATI: When you get a bunch of angry people together and complain about a product, you typically get the results you want.
No company wants to look bad, even to a minority of people. Because it often only takes a minority of people to completely trash a companies reputation, especially in such a competitive market like motherboards.
So if you know of any other manufacturers who have poor Linux support, don't be scared to send them a letter about it and to tell other people who use Linux about your problems with the manufacturer. You might end up afflicting positive change in the long run.
Great news, that's fantastic. I wonder what caused the problem in the first place?
Anyhow, I wonder what happened to that bitter person in Foxconn's tech support? Hopefully he will be taking things more seriously next time as well.
Twinstiq, game news
Quotes from the article:
So not just in this one high publicity case, but on all of their motherboards.
I would say you got what you want here. Time will tell.
I'd say they got this one done too. That's pretty public.
Yes, it's lame that it was broken but now it's fixed. One week is pretty quick for a BIOS revision spin. Maybe it's OK to cut them some slack on this one now.
Help stamp out iliturcy.
Now it will be interesting to see if all the people condemning Foxconn a short while ago, has the guts and hearts to take Foxconn into their grace again.
these guys really didn't have to EVER fix this, much less a week later. if all hardware manufacturers were this responsive the world of technology would be a better place.
Obama is a twitter sock puppet
use freedos...
MP3 Search Engine
Foxconn is probably just doing this to avoid negative publicity, despite the fact that BIOSes shouldn't be running any code specific to Linux, due to specific decisions by the kernel developers.
Quoting from an actual kernel developer:
Those sneaky Foxes are just out to Con us all!
Comment removed based on user account deletion
Informative? That's pure speculation.
More likely, they simply didn't go out of their way to support Linux. When they buy a BIOS it comes with default DSDT tables that of coarse don't work on their specific board, it's very possible that they fixed the Windows tables and ignored the rest.
But of coarse, mere incompetence doesn't make for a good Two Minutes Hate. Linux zealots say they love UNIX, but they really just love to hate Microsoft.
For someone who whines so much about Free software twitter, you'd have thought you'd actually know what you were talking about by being aware of FreeDOS.
It never gets trolled by Anonymous Coward. Move along, move along... Garrett's stuff doesn't get into the kernel unless the maintainers of the kernel like it, I've seen some of his stuff bounce. The man is not God.
See, the open source community can pressure companies into releasing compatible Linux hardware.
Taxation is legalized theft, no more, no less.
Well, as most linux users are tech-savy, they are often being asked advice by less tech-savy people e.g.
-- What do you think about this PC? Shall I buy it?
*looks through the specs*
Foxconn Mobo? Utter trash! Don't buy it!
I do think that linux users are not many, but we are influential for sure.
Congratulations, foxconn, for listening to your market.
NO SIG
Ryan1984's post makes it sound like a generic AMI BIOS problem with Linux ... I don't think this is the case. AMIBIOS runs well on Linux generically (it's on Sun Microsystems servers, the Asus EeePC & EeeBox, which all work with Linux) so this is probably Foxconn introducing a problem when they ported the BIOS to their boards.
Board manufacturers like Foxconn get a development kit from the BIOS manufacturer then port it to their platform. If Foxconn made a BIOS fix for Windows then didn't test it with Linux, this would cause the issue. A similar situation would be if a company made a variation of a Linux distro for their products but broke somethign that worked generically in the original distro.
I think the community response worked great for getting Foxconn to pay attention to Linux. They saw their business & reputation threatened and are trying to fix the problem.
move along, nothing to see here, here kiddies *candy* now go away.
Not forgiven.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
Willy - Take a look at what the original poster at Ubuntu forums said:
Ubuntu forum thread. Starts at post #114.
If he is correct in what he writes, then it doesn't seem much like speculation.
Perhaps if someone else has linkage to a sound refutation of his claims, it would be a good thing to post here. I've seen comments that TheAlmightyCthulu's claims were 'debunked', but the comments didn't say where, or have links.
"...there are some things that can beat smartness and foresight. Awkwardness and stupidity can." ~ Mark Twain
Yeah, right, deliberately. I guess you never make a mistake at your job right? So everything you do wrong was on purpose, you must be a terrible person.
I won't touch their product because I will never know if they'll deliberately break it with some future revision when someone pads their pockets. In this instance they got caught doing something dirty and now are scrambling to cover it up.
If they issue a press release on why this happened and state a commitment to ethical business practices along with their fixed production release I will be mollified.
If they were to release the source code to both version I will be appeased.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
His reasoning:
they went to great lengths to sniff for Linux, and hand it it's very own DSDT table, which was not only inappropriate for the hardware on the board, but also failed a checksum test, had multiple compiler warnings, and so on.
The assumption that the mobo manufacturer wrote the DSDT tables is a poor one. They licence a BIOS from someone else, and it comes with sample DSDT tables that probably won't work on the hardware. They then update the Windows tables to work with their board, and ignore the rest.
That scenario is entirely consistent with what was reported on the Ubuntu forums.
They didn't actually do anything dirty, they simply didn't do anything.
The problem is that the ACPI tables are handled according to the operating system installed and when the BIOS checked that linux was in use, it provided a null table. This is not because they purposely broke something, but because they failed to check the bios and follow through on it.
Evidently, and this is mostly my opinion, FoxxCon had no idea how much of a market Linux actually has or appears to have and took others at their word that it is too small to worry about. So they took a stock bios, made a few tweaks for the markets they thought would drive their sales and neglected to do anything about Linux. After they saw the response, they quickly and painstakingly got a workaround out and reversed their position because of the potential market size.
I over simplified the process there, there is a post obove this that goes into a good amount of detail. But it is more that they did nothing then that they did something dirty.
Yeah. This also seems to be an example of a more general phenomenon with Linux support, which is that the same company will make completely contradictory statements about their own Linux support. In the earlier slashdot story, someone from Foxconn is directly quoted as saying 'it doesn't support Linux;' now they say they always intended to support Linux. The truth is probably that they never even thought about Linux support, and then when the issue was brought to their attention random representatives started saying random things off the cuff.
I've had a similar experience with Amazon's MP3 store. If you want to buy entire albums (as opposed to individual tracks), you have to use special downloading software that they supply. The software was initially only available in Windows and Mac versions, but pretty quickly they brought out Linux versions as well. Nowadays when you use your Linux box to shop for albumbs on their site, if you don't have the software installed your browser will detect that, and detect your OS as linux, and they'll generate a page for you offering links to download a linux version of the downloader. In fact, they even have it available in multiple versions for different linux distros. However, the linux downloader has been pretty buggy for me (and was also hard to get working properly on x64). I've had it working, then it broke, etc. I've done two calls to Amazon's tech support about this, and in both cases, the initial reaction was to tell me to do a bunch of stuff (with the usual confusion because the Indian tech support person gives Windows+IE instructions, and has never heard of Linux), and then when that didn't help they checked with someone else, who told them Linux wasn't supported. Never mind that they've had Linux versions of the software up on the site for months now.
I think part of the problem is that so many people in the hardware and software industries live in a 100%-Windows environment. It honestly never even occurs to them that anyone is running any other OS. (In the case of Foxconn, they're not making mac-compatible boards, so it's probably true that 99% of their boards are being used with Windows.) Then when the issue comes up, they just deal with it off the cuff. It's like asking them what their policy is on recycling cardboard -- they probably don't have one, and they don't see why it's important.
Another problem may be that in a Windows monoculture environment, many people don't understand what a standard really is. They think Windows and Word and IE are standards. Instead of developing for the relevant standard, some PHB makes the decision that they're going to target something proprietary, calling that a "standard," and they think of it as extra work to add support for anything else -- when in fact, it would have made more sense just to support the standard properly in the first place.
Find free books.
What are you worried about, MS changing the DOS API or something? ;-)
Since Linux pretends to be Windows regarding ACPI, kernel has to emulate all windows' bugs or it won't work properly on some ACPI "compliant" hardware.
That knid of approach is a double edged sword. It keeps vendors out of ability to even differentiate between the two operating systems, while it allows many of them to work if ACPI tables for Linux are broken (this usually happens when it's completely untested like in this case). So don't blame Foxconn, it's not their fault entirely. They did a workaround (probably isn't that simple when you have OS that fakes it's identity) and for it they deserve positive publicity, not mindless bashing. Linux hater's blog has a good point about it.
Bigger blame lies on companies which designed that trainwreck ACPI standard in the first place.
I said about the earlier story that I wouldn't consider Foxconn kit because we use Linux based utilities to restore and troubleshoot Windows systems. Since they are acting to fix the issues, I have no reason to disqualify their stuff out of hand anymore.
Still a strange error to make, what if it doesn't match anything? Like:
switch( os ) {
// CODE
// CODE
// CODE
case win95/98/me:
break;
case win2000/xp/vista:
break;
default:
}
Did they put an empty "case linux: break;" in there? Or did it lack a default section at all?
Live today, because you never know what tomorrow brings
I can understand that line of reasoning, but then wouldn't it follow that Foxconn and/or other mobo manufacturers would likely have committed the same, or very similar, error at some point in time prior to now? With the same, or very similar, results as far as Linux running on that hardware?
What I am hoping for, or wondering at least, is: has anyone any solid evidence that this (what Willy posits) is the case?
If not, then that would seem to make this a first-instance occurrence of what would seem to otherwise be a likely common 'bug'. With the number of years Linux has been running on mobo's, and the number of different mobo manufacturers, and as many highly technical eyeballs are on their Linux installs and hardware, you would think that someone would have had, and seen, a problem like this long ago.
"...there are some things that can beat smartness and foresight. Awkwardness and stupidity can." ~ Mark Twain
as fellow slashdot users recommended me to in protest!
Maybe you guys should not overreact about issues and bring up the conspiracy theories next time huh?
Fuckin' A. Don't mess with Slashdot! To hell with the US Presidency being the most powerful position in the world. Slashdot is where the real seat of power rests! Seriously. We get things done. Take my word for it. Good ol' AC wouldn't lead you astray.
You went to the trouble of replacing *all* your Foxconn boards based on protestations you heard on /. and you're griping about other people overreacting? Twit.
What has this anything to do with Apple?
How did I coded shitty bios?
It wasn't just that the table was wrong, there was specific code in the BIOS to point to a a bad table.
This phrase, 'Never ascribe to malice, that which can be explained by incompetence', is absolutely a darkside distraction.
You've heard it so much over the years, that you start to believe it.
It's a *great* cover for darkside machinations.
Incompetence definitely exists, but to let yourself be deluded into thinking that bad things are due to incompetence is to show your own incompetence as a sentient lifeform.
Assume malice first, and search for proof of incompetence.
In this case, specific code was in the BIOS that was malicious.
You are being MICROattacked, from various angles, in a SOFT manner.
Complaining works? Then I'd like to complain about the phrase "going forward". There's enough buzzword bingo in work - I shouldn't have to deal with it here too. Perhaps if we got a bunch of angry people together to complain about marketingspeak, we could end up afflicting positive change in the long run?
http://mjg59.livejournal.com/
Quote :
Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified.
Well, it is definitely written into the APCI 2.0 specs. When implemented, the bios can check the OS running and give specific tables to the OS that ease compliance and nuances that are different among other operating systems.
If this is the case in which it happened that way, then it can be as simple as other mainboard manufacturers not using specific DSDT tables or referring all non recognized or handled returns as NT and providing NT versions of the DSDT tables. When Foxxcom's programmer decided not to acknowledge linux and/or forgot to point it back to the windows tables, we see an issue that is specific to one instance and manufacturer.
Make no mistake, they didn't write anything specific into the bios to check for linux. That is already there and part of the spec. Failing to handle the return properly is a mistake but it doesn't imply the malice accusations that are going around. And no, this first appearance doesn't mean it can't happen with the other manufacturers, it just means that it hasn't because they did something different or were more thorough. Linux mimics windows in a lot of ways on these levels and for the most part, can handle the windows DSDT returns. If a mainboad simply passes the windows tables on a linux return, you would likely never know the difference without the source or decompiling the bios.
....on the list of motherboard manufacturers that I'll never use again. In fact prety much all of them are on that list except for ASUS and Gigabyte (and ASUS have an icky bios interface).
I only buy pepper spray that's been tested on anti-vivisectionists.
Your observation appears to be on target:
Solaris Express build 94 running on ECS GeForce7050M-M:
$ smbios
ID SIZE TYPE
0 71 SMB_TYPE_BIOS (BIOS information)
Vendor: American Megatrends Inc.
Version String: 080014
Release Date: 08/28/2007
and Ubuntu 8.04 i386 running on ASUS M2N-MX-SE
# dmidecode
# dmidecode 2.9
SMBIOS 2.4 present.
49 structures occupying 1827 bytes.
Table at 0x000F06F0.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 0403
Release Date: 08/20/2007
maybe they learned from asus that they can use their Linux userbase as a good card in their stack when dealing with Microsoft.
molmod.com - computing tips from a molecular modeling
I can't believe the phrase "going forward" is reaching slashdot summarys now.
A little part of me dies each time I hear that phrase, and working for a FTSE 50 insurance company I barely survive each day.
nm
Still a strange error to make, what if it doesn't match anything? Like:
switch( os ) { // CODE // CODE // CODE
case win95/98/me:
break;
case win2000/xp/vista:
break;
default:
}
Did they put an empty "case linux: break;" in there? Or did it lack a default section at all?
That's not far from the truth. The ACPI table in the released BIOS was only useful if you were running Windows XP or Vista (possibly also 2000, can't remember now).
> Anyway. Accusing companies of conspiring against us when the most
> likely explanation is simply that they don't care is a fucking
> ridiculous thing to do and does nothing to get rid of the
> impression that Linux users are a bunch of whining childish hatemongers.
Yeah, but strangely enough it seems to have worked and worked so well we Linux users
got positive results in less than a week. So the lesson I've learned from this is if
some hardware manufacturer is going out of their way to make it difficult for me as
a linux user to use the hardware then bitching at them in a public forum and incurring
the wrath of fellow slashdot readers produces what I consider positive results:
hardware that works with Linux.
Sounds like a missing default section.
I've looked at the DSDT on that system the this is clearly a bug that unfortunately is manifesting on Linux systems. The Acquire statement was stupidly placed there with a timeout of 1000 ms -- it should not have any timeout. It's there to protect the PCI config space access ports. The funny thing is that those functions don't appear to be called from any other AML in the DSDT. The only thing that's used is the OSVR variable, which is used to make several decisions surrounding the suspend functionality. Another interesting thing is that since Linux has been reporting its os version as "Windows NT" for a long time now, the bug will affect any os that reports itself as "Windows NT" also.
I'm surprised noone is comparing this saga to the AARD scandal that ultimately resulted in Microsoft having to pay a settlement to Caldera. you can read about it here http://en.wikipedia.org/wiki/AARD_code but the case was about encrypted & obfuscated code inserted in Windows 3.1 to detect DR-DOS and preventing Windows from running on it. Internal Microsoft memos revealed the intention of the code: At one point, Microsoft CEO Bill Gates sent a memo to a number of employees, reading "You never sent me a response on the question of what things an app would do that would make it run with MSDOS and not run with DR-DOS. Is there [sic] feature they have that might get in our way?"[1] Microsoft Senior Vice President Brad Silverberg later sent another memo, reading "What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS"[1] Later, after DR-DOS had been purchased by Novell and renamed "Novell DOS", Co-President Jim Allchin stated in a memo, "If you're going to kill someone there isn't much reason to get all worked up about it and angry. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger."[1] The lawsuit was later settled.[1][2] Compare this to: "One thing I find myself about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific. If 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 Io 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 relaled to this." In both cases it was Bill Himself that suggested to employees that they threw a wrench into something to prevent competing o/s'es from interoperating properly. Many of you probably know about the AARD scandal for I wanted to post this for those who don't :)
That's right -- and AMI makes their money by intentionally NOT taking fixes from their customers and integrating them into their core (so that when problems crop up, they can offer their "services" to help fix them) -- it's like pulling teeth getting them to take a fix upstream, believe me. AMI sucks just as much as any other BIOS vendor.
Sir, could you please explain how adding a second table "for Linux" amounts to doing nothing?
It's not the BIOS' job to detect the OS. The OS reports what it is to the BIOS (Linux reports as "Windows"). In this case, Foxconn added checks to be sure that if Windows was reported, it wasn't actually Linux faking. If they just had passed the Windows table to Linux, everything would be fine and dandy.
The BIOS was dissassembled and showed exactly that. They did infact go out of their way to NOT support linux.
Which one will you trust? The Foxconn Renaissance looks good, but I'll probably go with the Asus T6T-VC1 just to be safe.
See, you can make change.
President/CEO Pacy World http://www.pacyworld.com
Good job with that rep Foxconn. Now we can say `I Heart Zhang.'
It is likely that other manufacturers put in a default to statement and then sends it to windows.
Something like
If
OS$ = A$ then A
OS$ = b$ then B
else default
default=NT or whatever the hex is.
Now don't beat me up, I'm not a programmer and I don't play one on TV. But hopefully, you get the Idea, set a default, if a return is something recognizable, goto the setting for it. If it isn't, then default. From what I understand, they failed to put the default return or the "if else" in which meant when it discovered linux, because it wasn't told what to do, it freaked and stopped or made some shit up with an error or something. If it defaulted back to windows, then things would have been ok with no issues other then the common ones around the biz. From what I can tell though, we are actually better off now because instead of letting us use the windows tables, they are going to be actively working for compatibility with Linux specifically.
I guess they found out how large the tiny Linux market was. And if they work on making sure their boards have compatible drivers or that OSS drivers will work, they might get a big chunk of that market. It sort of sounded like we might finally have a manufacturer who is going to make Linux compatibility a feature instead of some ancillary. There might already be some out there that do too, but I can't think of them off the top of my head.
It was completely understandable. The only problem there is on your side.
In the original Ubuntu Forums thread, some people said the story needed to be Dugg (which it was). Later, a voice of reason said that the story should be submitted to Slashdot so that they could find out what was really going on in the BIOS.
I'm proud that Slashdot has the rep of having really smart posters who know their shit.
BTW, I was always in the "bad copy-paste" camp.
Put identity in the browser.
The assumption that the mobo manufacturer wrote the DSDT tables is a poor one. They licence a BIOS from someone else, and it comes with sample DSDT tables that probably won't work on the hardware. They then update the Windows tables to work with their board, and ignore the rest.
So how is that a poor assumption? If they did that, they simply didn't think about Linux and didn't test it. I'm sure the tables didn't work for BSD, Plan 9, and various other OSes that they didn't care about.
This was clearly not malicious. Anyone who thinks it was should get back in their bunkers before the government mind readers find them again. Bugs happen. A lot. Deal with it.
What would help this ACPI table business?
Very simple - the Microsoft ACPI Table compiler is Broken. Typical Embrace and Extend from Microsoft.
They're already into the "Extinguish" Phase.
The Irony is that intel, who designed the ACPI spec, has freely available an ACPI table compiler that works under both UNIX's and windows.
Which isn't broken.
However, MS has been successful in taking the bios tool-making market - Which they really have absolutely no business in being in - they are NOT a computer engineering company, and i would advise all ENGINEERING firms to remember that.
When there's an Issue, the buck stops with the engineering firm who was stupid enough not to realize that Microsoft are careful to insulate themselves from any and all liability.
MS are all about profit without responsibility.
But then, that exemplifies all that is wrong with our capitalist system.
Shareholders happily take their share of profits, safe in their safety-of-numbers from any responsibility to the rest of the world.
What Foxconn did was wrong, and they screwed up by not testing it properly. But the situation becomes worthy of ridicule when random Linux users concoct conspiracy theories based upon no facts whatsoever. Nobody knows whether it was malice or incompetence that produced a buggy Linux table, but assuming bad faith in this is the very definition of chip on the shoulder in a situation like this. Baseless speculation contained in a forum post with zero supporting evidence that malice was taking place. The user was speaking on things he/she knew absolutely nothing about, and yet it was taken as 'news.'
(Then again, it fits right in with the comments on this site.)
they're chinese. they need to save face. you have to understand someone's millenia-old culture prior to judging.
PS: that's the sort of arrogance the world over is reproaching to the US.
Congratulations Willy you've turned into Twitter.
Without even reading the original article you started speculating. You're currently spewing bullshit just like your rival that you love to spam at.
The actual code shows they didn't ignore but actually added Linux specific code to the BIOS. The same BIOS kit used by the asus eeepc, etc.
I'm not purposing they intentionally did it but my god you don't even fucking read, you just side with Microsoft the same way Twitter sides with GNU and the FSF.
Stop being a douchebag .
Comment removed based on user account deletion
...if that's what you believe (not necessarily directed at you). Screw Mod Points, Karma, and whatever else. State your piece!
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
You guys don't understand how serious is this foxconn issue.
If foxconn didn't support linux.
Why these linux _OSI specific statements even exist in the foxconn BIOS code?.
The answer to this question is very clear. Foxconn has delivered corrupted linux ACPI code purposely in reponse to "some big company" pressure.
We don't need to be genius to find the analogy with the AARD code scandal.
If you have one of these boards, you need DOS to fix the BIOS.
If Gigabyte's most recent motherboards are any indication, this kind of problem will slowly become a thing of the past. Recent Gigabyte boards, ones with an 'S' in their model name (S=Smart/Safe), have a back-up BIOS copy on the ROM, and the BIOS now has the flashing code builtin, so one BIOS copy can flash-update the other BIOS copy (even getting the actual update patch via the net), eliminating the need for any boot disk.
Its still a non-free BIOS, so its not perfect, but it at least eliminates the need to keep that ridiculous DOS floppy disk around just for flashing junk every once in a blue moon...
FWIW, I have no idea why you were modded Troll. Looks like /. is giving out mod points to just about anyone nowadays...
I admin for someone with a Dell that has a Foxconn GM33 variant in it (and I believe this BIOS fix is related to the GM33). It has worked fine in Ubuntu until upgrading to Hardy. With Hardy the kernel issues SATA errors and fails to boot completely.
There's a workaround involving either tweaking a BIOS setting or adding kernel options, but this is utterly lame from a user-centered point of view -- which is what both Ubuntu's and Dell's strength is supposed to be.
If Grandma upgrades from Gutsy to Hardy her PC shouldn't fail to boot. And I shouldn't have to tell Grandma over the phone to hit Delete quickly enough to get into the BIOS, and then try to guide her through screens that are gibberish to her. I can't believe this bug was foisted on users and then not rapidly nailed.
I should note that this particular model is *not* one that Dell offers with an Ubuntu pre-install -- in other words, Dell hasn't given any promises that it should work with Linux. But if this BIOS update does fix the problem, I hope Dell steps up and offers it officially.
Your right, the BIOS doesn't specifically look at the hard drives and say X is installed on the computer. What it does is reports that ACPI is enabled and if the OS is able to, it can use it. When the OS attempts to use it (which all moder OS's do) it presents the BIOS with an Identification string then the BIOS reterns any specific values it has for that OS if it has used the DSDT portion of the APCI 2.0 spec. In the case of Foxxcon, it didn't return anything or returned errors because it didn't know how to handle linux. Some main boards don't even use that so it would be a default return regardless.
They did not "write some program into the bios" that checked is Linux was installed and then purposely screw it up. What they did was fail to handle linux properly on the return. They could have sent a default windows back or they could specifically write for linux but instead, they did nothing. The ACPI part of the BIOS is "an abstraction layer between the OS and platform firmware and hardware. This abstraction allows the OS and the platform to evolve independently. Not only should a new OS be able to handle old hardware, but an old OS should be able to handle new hardware." When Foxxcon decided to implement the Differentiated System Description Table (DSDT) for their boards, they didn't provide a default fall back or Linux specific information which caused the faults.
Now it is entirely possible that it was some other part that failed to return properly as the spec is quite large. But this problem wasn't the result of malice.
Yes, and Linux identifies itself as Windows. But how come Windows was presented with a proper DSTD table, and Linux not, when they both identify as the same OS?
They value all their Lunix customers... and promise to do everything possible to keep those 14 people happy.
Sumdumass always vigorously defends his corporate masters, whether it concerns their "moral right" to close down GPL code with DRM, or as in this case, deliberately break ACPI if Linux is detected.
Er.... And while, obviously, MS has done dodgy shit in the past (e.g. DR-DOS + Windows 3.1), unless you have actual evidence that there is a conspiracy of malice rather than a bunch of clueless firmware authors, can you please not make accusations? Your stupidity makes everyone in the Linux community look bad to the outside world. If you do have evidence, please post it in a calm manner, instead of this OMG MONOPOLYSOFT ARE PAYING OFF LINUX ACPI DEVELOPERS bullshit? Thanks.
Yes, since there is no real standard for how it is supposed to work, Linux reports itself as (and attempts to emulate) Windows. Yes, it sucks, but it is better than having vendors include workarounds for Linux bugs and Linux then never being able to fix them.
As someone pointed out earlier, while it has had a relatively good outcome (Foxconn working with a Linux ACPI person to make Linux and the BIOS suck less), this "Ryan" guy has, unnecessarily, been a total dick and ranted and raved about things he clearly doesn't really understand (and has no interest in learning about).
Exactly. This is the conclusion that can be drawn from this story.
Take a moment to hover your mouse over the name of the parent poster, and you'll realize who you're really talking to.
Since when has windows followed specs? Lets see here, linux follows the spec and works most of the time, Microsoft embraces and extends and magically works when other things don't.
Anyways, it seems that the problem is actually due to AMI and not Foxconn itself. It appears the same problems are happening with some Asus and MSI boards too. All of which are using AMI BIOSes.
Now, if you were to read Matthew Garrett's Journal, you can see the OS checks in question. Garrett is someone of knowledge to the situation and has been attempting to help with it.
But if you look at the first link, you can see the OS check and what the options are. If the NT or Unknown or even the ME or older linux return is somehow passed back, it could be possible that there is simply no support for it or the support wasn't optimized the the board because the OSes aren't in service anymore. But you will alsoo see from that site that
It can be worse when you consider the OEMB tables error. The OEMB is defined according to this VMware thread as
Now, if you ask me, and I'm mostly using the power of deduction from actually paying attention to what's going on, the DSDT overrides parts of the RSdT which is modified by the OEMB. The OEMB in these AMI BIOSes maintain something that isn't compatible with any return other then the windows 2000/XP/vista return and somehow, the AMI bios is setting the linux Identity to something other then 0 which would be the Windows 2000/XP/Vista return. This is probably the root of the problem and most likely what AMI fixed to allow Foxconn to get thing going on a new bios. You have to remember that windows can also use PNP as a fall back to the OEMB information and just set the hardware setting to a sane default value based on similar chipsets and such.
But, this part is speculation on my part. What isn't speculation is that Malice on Foxconns part isn't at play.
Lol... Not allowing unsigned code to run on a device is not closing GPL code down. It is closing the device down and you still get the code. My issues there is the reach and scope of what was being done. If the government of any country does something along the same lines, you would be the first in line crying fowl over the encroachments.
And no, they didn't deliberately break anything if Linux is detected.
Another thing, what I'm defending against is improper accusations being made because of ignorance. Of someone made an untrue claim about you, I would defend you just as vigorously. I think it is more telling of you using the term "corporate masters" then anything I have said. So don't expect me to defend you over true accusations. You reap what you sow and I think there is enough unsubstantiated FUD floating about.
Wrong person. wiIIyhiII (1327445) is not willyhill (965620).
twitter figured out the correct combination of letters to run a proper joe job on the person that has the temerity to document his bullshit after trying many times.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
What isn't speculation is that Malice on Foxconns part isn't at play.
You don't know that. Actually, that's speculation on your part.
the idea of you getting modded up for stupidly and clumsily aping a way of thinking you hate so much brings unending joy to my heart