Updates of resolution od Foxconn bug ( no debates please just updates)

[mjg59]

-Why has the BIOS a reference to "Linux" when there is no equal use of kernels in linux, and the kernels present themselves as the corresponding Windows version?

Because it's old code that's present in multiple BIOSes from several vendors, which makes me suspect that it's originally part of some Intel sample code. When a new motherboard gets released, the ACPI tables aren't written from scratch - they're usually just modified from the previous motherboard. This code wasn't breaking anything, so nobody ever got around to removing it.

-Is this nessesary?

No.

[Fitzcarraldo]

No. There's a difference between not being standards compliant and having a bug (though I remain unconvinced that there's a bug in anything other than Linux here).

As a neophyte I'm trying to understand the source of the problem, and have a few genuine questions:

Apparently Foxconn, and now AMI, are working on a change to the BIOS of various mobos. If there is no bug in the BIOS, what are they changing, and why? Presumably, if they thought the fault lay with Linux, they would say so?

This issue seems to be a hot topic on many Linux-related forums and blogs at the moment. However, as far as resolution of the problem is concerned, all I have read so far relates to the BIOS supplier working to implement a change to the BIOS. If you believe there is only a bug in Linux itself, is anything happening on the Linux side? If this is a possible bug in the kernel, is anyone from the Linux kernel team investigating the problem and trying to come up with a fix for the kernel?

[mjg59]

Apparently Foxconn, and now AMI, are working on a change to the BIOS of various mobos. If there is no bug in the BIOS, what are they changing, and why? Presumably, if they thought the fault lay with Linux, they would say so?

Given the press, how would Foxconn announcing that the bug is in Linux be received? Right now it'd still be perceived as them trying to pass the buck. Linux bugs can often be worked around in the BIOS, so that would be one approach - alternatively, they're just showing willing in trying to diagnose the real problem.

This issue seems to be a hot topic on many Linux-related forums and blogs at the moment. However, as far as resolution of the problem is concerned, all I have read so far relates to the BIOS supplier working to implement a change to the BIOS. If you believe there is only a bug in Linux itself, is anything happening on the Linux side? If this is a possible bug in the kernel, is anyone from the Linux kernel team investigating the problem and trying to come up with a fix for the kernel?

I'm travelling at the moment, but I've arranged to get hold of the motherboard in question once I'm back home (mid next week). I ought to be able to track down the source of the problem then.

[Neckbeard]

I read of much interest your postings, as I understand you are very cunning in this matter.
None has answered my former questions, so I ask you to do it:
-Why has the BIOS a reference to "Linux" when there is no equal use of kernels in linux, and the kernels present themselves as the corresponding Windows version?
-Is this required?

I think this explains it:

http://en.wikipedia.org/wiki/Cargo_cult_programming

[Neckbeard]

Given the press, how would Foxconn announcing that the bug is in Linux be received? Right now it'd still be perceived as them trying to pass the buck. Linux bugs can often be worked around in the BIOS, so that would be one approach - alternatively, they're just showing willing in trying to diagnose the real problem.



I'm travelling at the moment, but I've arranged to get hold of the motherboard in question once I'm back home (mid next week). I ought to be able to track down the source of the problem then.

Foxconn has admitted that this is no problem on same chipset with Award BIOS.

If a Linux bug, then why does everything get fixed on identical hardware with the Award BIOS?

I'm believing at the moment it's a bad BIOS and not Linux, or that if it is Linux, this BIOS is triggering the problem at any rate while most other BIOSes don't?

The latter sounds very unlikely (that it's a Linux bug) just for that.

[Neckbeard]

I was just reading some more, he also mentions FreeBSD is similarly afflicted with the reboot after suspend error?

[vanessaezekowitz]

In response to the original thread, I sent Foxconn an email letting them know how I felt. I don't have a foxconn system, but I'm always watching for good deals on hardware, so I felt this might affect me some day. Call me a fangirl if you want, I'm very passionate about Linux.

Here's what I originally wrote:

I recently read of an attempt by your company to explicitly manufacture boards that use a damaged BIOS, which results in improper, non-compliant ACPI configuration data being returned when a Linux-based operating system is being run. According to the report, your PR department has explicitly and clearly stated that you will not support Linux. Why then, does your BIOS data include deliberately broken entries for Linux? If you had simply stuck with code/data that is fully compliant to the ACPI specification, this issue would not crop up. No doubt you've heard plenty of complaints by now due to the news being covered on Slashdot. If your management is smart, they will find and fire the person(s) responsible for this outrage, and fix it post-haste. Slashdot can, as you are no doubt also aware, severely damage large companies' reputations when those companies get out of line. I am disgusted by this practice, I find it outright reprehensible, and will NEVER buy any hardware made by your company.

...Needless to say, I was just plain ticked off. They responded with a link pointing to some kind of issue tracking system. Therein was this reply:

Dear Vanessa Ezekowitz
Thank you very much for your attention with Foxconn.
With regard to this issue posted on the websites, we are trying to resolve it and we would like to state here that Foxconn will never reject Linux.
If you meet similar problems, please try to provide your detailed configuration, (including cpu, memory, hdd, Linux version and its kernel, etc.) and the symptom so that we could test in our bed and analyse to resolve this.
It is really a pleasure to be of service to you, [ma'am].
Thanks and best regards,
Foxconn Technical Support

(corrected a pronoun error in their reply).

Figured their reply would be interesting to others here.

[saaya]

Hi all,
I work for Foxconn QuantumForce, the highend desktop parts, different department but Ill try to help out

First of all thanks to KiwiNZ and the admin and moderator team on the forums here for trying to keep things calm and solution focussed

Second of all thanks to mjg59 for shedding some light on the actual problem and answering peoples questions around here
If there is anything i can do to help you or somebody you know who can fix this problem and improve the compatibility in future people let me know.

It will be extremely interesting to see where this ends up, my idea is (without speculating as to the cause of the problem), that someone's boss(es) are aware of the situation that has brewed, and that they're being ridden to provide a BIOS that works well with Linux.

As for their reasoning, I don't care, I just want them to take accountability and fix it, they owe their customers an ACPI compliant board, as advertised, even if they don't go out of their way to advertise that it works with Linux.

The tech support guys you talked to didnt do anything wrong in my opinion and they told you the same thing ANY mainboard vendor will tell you. And sorry to dissapoint you, but no, nobody here is in trouble or gets poked by their bosses because of what you said or did.

all your whining and blaming foxconn for deliberatly cripping linux has achieved is people here at foxconn taking the open source community less serious, which is very dissapointing imo.
unfortunately there are still quite some people who believe in the myth of the louder you complain the better you will be treated...

I think Foxconn recognizes that shoddy programming and support is unacceptable. The 150k+ views should tell them that.

about the programming i cant comment, but as far as i know the troublesome code isnt written by us but by AMI and is used by every mainboard vendor who uses AMI BIOS kernels. about the support, could you please tell me what exactly is so shoddy about it? he told him the same thing any tech support will tell you, its not supported... and he event went ahead and offered to try and fix it but was only threattened and harassed by almighty. For the record, our tech support guys started to check on this and are looking for a fix ever since almighty first contacted them, not after almighty spammed the net with negative propaganda about foxconn!

And If CBrunning is not getting the upper level support he needs, perhaps he should ask his superiors if Foxconn is serious about upholding the marketing departments claim of Linux ACPI support.

correct me if im wrong, i work for a different department, but as fas as i know foxconn never claimed linux support to begin with... and a part of the community stoning foxconn before we even started working with the community isnt really helping in creating a good and efficient relationship, now is it?

I was about to say the same. Even if things go a little over the top any attention and focus brought to these issues can just be beneficial, thanks to a kind of fortunate mingling of two separate topics, i.e. ACPI standard compliance and the claim of maybe intentionally breaking Linux. Regardless the latter, this obviously is a good time to seek and urge for advances on the former.

I'd expect especially Linux developers to be pleased, as they have been complaining often enough about the sad state of affairs, needing them to reimplement Windows behavior "bug for bug". If I were one, I'd think I could expect my voice of concern being heard sooner in the future.

on the contrary, all that is achieved if some people who dont even get their facts straight create the manufacturers a big headache, is that the REAL open source community who is trying to get someting done and improve things, is taken less serious or might even be ignored.

would you want to work with somebody who might visit opra and other tv shows one day trying to discredit you, just cause he got upset over some bug that isnt even your fault?

"Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a ******* ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?"

exactly...

If the end result is better, more consistent and ultimately more functional power behavior under Linux, for everyone, then the ol' Ryan will have done some good.

if the end result is anything good it will be because smart, dedicated hard working people from the open source community and foxconn will work on this and find a solution and NOT because almighty created a pr nightmare for foxconn.

Bug fix or no, their customer support seems to have improved.

i dont see any change in tech support at all... but if your happy with the support now, good

No kidding, I saw how they were behaving before, there is no excuse for this.

then tell me, how were "they" behaving? they were polite throughout the whole time from what ive seen, even when almighty pressured them and provoked them. and even after all the headaches he caused them they were actually working on a fix and still are.. so what exactly did they do wrong?

Thank you, I had just noticed this when you had said something about it, all of the Google results are hogged by the original "sabotage theory", it does look like Microsoft had a major part in this and is trying to stay out of the spotlight by letting AMI do dirty work for them, it looks like ASUS and MSI boards are also affected.

Ouch, this is a mess now matter how it came about!

its possible that microsoft provided this code to AMI, but the fact that the code seems to be outdated is not microsofts fault and surely not a sabotage attempt...

All you guys getting a "this motherboard does not support linux" answer from your support, just do what TheAllmighty did

sure, if you want to kill off manufacturer support for linux all together, go ahead. if you actually want to do something to improve the situation you might want to try and work WITH the manufacturers and not against them.

just like somebody posted in this thread, the problem of the open source community is that there isnt ONE organisation that certifies standards like MS or Intel or AMD etc do. So imagine you want to sell a product that complies with Linux... how would you ensure it works well with all the main distributions out there? for MS Intel AMd etc its easy, you submit your product and they will evaluate it and help you to get it compliant. with linux its not that easy...

I really like the idea of open source and want to support it, but its really not easy... its not even about the money it costs or the work it takes, there is just no unified concept to certify compatibility... at least as far as im aware of...

Given the press, how would Foxconn announcing that the bug is in Linux be received? Right now it'd still be perceived as them trying to pass the buck. Linux bugs can often be worked around in the BIOS, so that would be one approach - alternatively, they're just showing willing in trying to diagnose the real problem.

I'm travelling at the moment, but I've arranged to get hold of the motherboard in question once I'm back home (mid next week). I ought to be able to track down the source of the problem then.

At the moment nobody KNOWS what the issue is, so of course our engineers are working on it and are trying to solve it. And regardless of where the problem lies, im pretty sure the problem can be fixed on both sides...

I really dont like how many people are focussed on who is to blame... ami, microsoft, foxconn, linux... does it matter?
we should all focus on getting the problem fixed and making it work! maybe its a problem of the BIOS but its easier or more reasonable to fix it in linux somehow to prevent somthing like this or something similar to happen again? after all foxconn boards arent the only ones using this ami code, so if it can be fixed in linux without too much hassle, that would be the best thing as it would fix the problem overall for ALL boards, wouldnt it?

if you have any questions or want to help in improving foxconns linux compatibility or foxconns relations to the open source community please let me know! I might be able to hook some penguin veterans up with our engineers which should help a bunch to imrove future support
i wish i could have a chat with linus or the round table of the elders, but i have no idea how we could approach them... if anyboy can hook us up, let me know!

and to almighty etc: i heard about this before the PR mess and negative propaganda was spread on the net, and all it caused was me and others reconsidering if we should even try to get involved or just ignore it... but after seeing that at least a part of the community here is actually interested in improving things and working on this, me, carl and others have decided to try and support them. Dont think this only happened cause of your whining and complaining, on the contrary... i recommend you some anger management training and hope you will think about what your trying to achieve and how you can achieve it first next time.
next time if you cant open a door you might want to try ring the bell or try another door instead of using explosives to blow the doors and windows open and cause a mess for everybody on the entire block.

all you achieved is discrediting yourself and unfortunately a part of the open source community to foxconn, the press and even the FTC! congratulations! thats quite an achievement in only one or two weeks...
you know what? microsoft should hire you and more people like you to do just what you did here, if they really want to sabotage the open source community.

[mjg59]

Foxconn has admitted that this is no problem on same chipset with Award BIOS.

If a Linux bug, then why does everything get fixed on identical hardware with the Award BIOS?

Ok, so there are two issues here. The first is that ACPI is a complex specification (over 600 pages) and it's very easy to write two different implementations of the same code that will trigger entirely different paths in the OS. The second is that ACPI defines only a small subset of the hardware behaviour. The legacy BIOS code (x86 assembler, not ACPI bytecode) is responsible for much of the initial hardware setup and suspend and resume handling. Different implementations may program the hardware differently, and Linux may work fine with one setup and not the other.

I'm believing at the moment it's a bad BIOS and not Linux, or that if it is Linux, this BIOS is triggering the problem at any rate while most other BIOSes don't?

The latter sounds very unlikely (that it's a Linux bug) just for that.

It's really not very unlikely. I've done a lot of work with BIOS code in the past.

[Neckbeard]

Hi all,
I work for Foxconn QuantumForce, the highend desktop parts, different department but Ill try to help out

First of all thanks to KiwiNZ and the admin and moderator team on the forums here for trying to keep things calm and solution focussed

Second of all thanks to mjg59 for shedding some light on the actual problem and answering peoples questions around here
If there is anything i can do to help you or somebody you know who can fix this problem and improve the compatibility in future people let me know.

The tech support guys you talked to didnt do anything wrong in my opinion and they told you the same thing ANY mainboard vendor will tell you. And sorry to dissapoint you, but no, nobody here is in trouble or gets poked by their bosses because of what you said or did.

all your whining and blaming foxconn for deliberatly cripping linux has achieved is people here at foxconn taking the open source community less serious, which is very dissapointing imo.
unfortunately there are still quite some people who believe in the myth of the louder you complain the better you will be treated...

about the programming i cant comment, but as far as i know the troublesome code isnt written by us but by AMI and is used by every mainboard vendor who uses AMI BIOS kernels. about the support, could you please tell me what exactly is so shoddy about it? he told him the same thing any tech support will tell you, its not supported... and he event went ahead and offered to try and fix it but was only threattened and harassed by almighty. For the record, our tech support guys started to check on this and are looking for a fix ever since almighty first contacted them, not after almighty spammed the net with negative propaganda about foxconn!

correct me if im wrong, i work for a different department, but as fas as i know foxconn never claimed linux support to begin with... and a part of the community stoning foxconn before we even started working with the community isnt really helping in creating a good and efficient relationship, now is it?

on the contrary, all that is achieved if some people who dont even get their facts straight create the manufacturers a big headache, is that the REAL open source community who is trying to get someting done and improve things, is taken less serious or might even be ignored.

would you want to work with somebody who might visit opra and other tv shows one day trying to discredit you, just cause he got upset over some bug that isnt even your fault?

"Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a ******* ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?"

exactly...

if the end result is anything good it will be because smart, dedicated hard working people from the open source community and foxconn will work on this and find a solution and NOT because almighty created a pr nightmare for foxconn.

i dont see any change in tech support at all... but if your happy with the support now, good

then tell me, how were "they" behaving? they were polite throughout the whole time from what ive seen, even when almighty pressured them and provoked them. and even after all the headaches he caused them they were actually working on a fix and still are.. so what exactly did they do wrong?


its possible that microsoft provided this code to AMI, but the fact that the code seems to be outdated is not microsofts fault and surely not a sabotage attempt...

sure, if you want to kill off manufacturer support for linux all together, go ahead. if you actually want to do something to improve the situation you might want to try and work WITH the manufacturers and not against them.

just like somebody posted in this thread, the problem of the open source community is that there isnt ONE organisation that certifies standards like MS or Intel or AMD etc do. So imagine you want to sell a product that complies with Linux... how would you ensure it works well with all the main distributions out there? for MS Intel AMd etc its easy, you submit your product and they will evaluate it and help you to get it compliant. with linux its not that easy...

I really like the idea of open source and want to support it, but its really not easy... its not even about the money it costs or the work it takes, there is just no unified concept to certify compatibility... at least as far as im aware of...

At the moment nobody KNOWS what the issue is, so of course our engineers are working on it and are trying to solve it. And regardless of where the problem lies, im pretty sure the problem can be fixed on both sides...

I really dont like how many people are focussed on who is to blame... ami, microsoft, foxconn, linux... does it matter?
we should all focus on getting the problem fixed and making it work! maybe its a problem of the BIOS but its easier or more reasonable to fix it in linux somehow to prevent somthing like this or something similar to happen again? after all foxconn boards arent the only ones using this ami code, so if it can be fixed in linux without too much hassle, that would be the best thing as it would fix the problem overall for ALL boards, wouldnt it?

if you have any questions or want to help in improving foxconns linux compatibility or foxconns relations to the open source community please let me know! I might be able to hook some penguin veterans up with our engineers which should help a bunch to imrove future support

and to almighty etc: i heard about this before the PR mess and negative propaganda was spread on the net, and all it caused was me and others reconsidering if we should even try to get involved or just ignore it... but after seeing that at least a part of the community here is actually interested in improving things and working on this, me, carl and others have decided to try and support them. Dont think this only happened cause of your whining and complaining, on the contrary... i recommend you some anger management training and hope you will think about what your trying to achieve and how you can achieve it first next time.
next time if you cant open a door you might want to try ring the bell or try another door instead of using explosives to blow the doors and windows open and cause a mess for everybody on the entire block.

And the spin cycle begins.....

You guys have no excuse to treat people like that, it was obvious you never planned on fixing the problem, that is provided you really work for Foxconn.

I sent an email about you to this Heart Zhang and Carl Brunning, referencing this post, we'll find out shortly I suspect.

I suspect more likely you're from the Linux Hater's blog here to spread FUD.